---
title: "Day-1 style system design question"
url: https://daily.dev/posts/day-1-style-system-design-question-08pqx7fqm
source_url: https://daily.dev/posts/day-1-style-system-design-question-08pqx7fqm
type: freeform
source: "django"
author: "Sizan"
published: 2026-06-08T04:19:55.707Z
updated: 2026-06-08T04:21:10.268Z
reading_time: 2
upvotes: 1
comments: 4
language: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Day-1 style system design question

**[django](https://daily.dev/sources/djangoarchitects)** · [@sizan5](https://daily.dev/sizan5) · 2 min read · 1 upvotes · 4 comments

## Summary

A system design scenario where a PostgreSQL database is overwhelmed by simultaneous OLTP and OLAP workloads, causing checkout API latency to spike from 120ms to 4s. Four scaling strategies are presented: read replicas, Redis caching, migrating analytics to a data warehouse, and vertical scaling. Readers are challenged to identify which single option best solves the core architectural problem long-term, with the answer promised in comments.

## Content

Your reporting service is crushing the production database every morning at 9 AM.

Finance exports a “Monthly Revenue Report.”
Operations opens a “Top Selling Products” dashboard.
Managers refresh KPI widgets every 30 seconds.

Meanwhile, your checkout API latency jumps from 120ms to 4s.

The problem:
your OLTP database is handling transactional traffic and heavy analytical queries at the same time.

Current setup:

Web App → PostgreSQL Primary DB

Checkout API → PostgreSQL Primary DB

Analytics Dashboard → PostgreSQL Primary DB

Daily Reporting Jobs → PostgreSQL Primary DB

…and traffic keeps growing.

You’re asked to reduce load on the primary database without breaking real-time transactions.

What do you do?

A) Add Read Replicas — route reporting and dashboard reads away from the primary database.

B) Introduce Redis Cache — cache report responses and dashboard queries.

C) Move analytics workloads to a Data Warehouse — isolate OLAP from OLTP entirely.

D) Increase PostgreSQL CPU & RAM — vertically scale the database server.

Three of these are valid production strategies.
Only one solves the core architectural problem long-term.

Pick one — A, B, C, or D — and tell me why.

I’ll drop the full breakdown in the comments (including why one of the “good” answers becomes a disaster at scale).

If your team has ever fought over scaling databases, share this with them. The tradeoff discussion is the real lesson.

Drop your answer 👇

## Community discussion

Top comments from developers on daily.dev.

**@sizan5** · 1 upvotes

> ### Why D is the trap answer
>
> #### D) Increase CPU & RAM
>
> Vertical scaling works…
> until it doesn’t.
>
> Yes, stronger hardware may buy time:
>
> - faster queries
> - larger memory buffers
> - more concurrent connections
>
> But:
>
> - cost increases rapidly
> - scaling has hard limits
> - architectural bottlenecks remain
>
> You’re treating symptoms, not workload design.

**@sizan5** · 1 upvotes

> ### Correct Answer: C) Move analytics workloads to a Data Warehouse
>
> #### Why C is correct
>
> The real issue is that the same OLTP database is serving:
>
> - transactional workloads (checkout/orders/payments)
> - analytical workloads (aggregations, reports, dashboards)
>
> These workloads have fundamentally different access patterns.
>
> Transactional systems need:
>
> - low latency
> - fast writes
> - row-level operations
> - strict consistency
>
> Analytics systems need:
>
> - large scans
> - aggregations
> - joins across millions of rows
> - long-running queries
>
> A data warehouse separates OLAP from OLTP.
>
> Typical...

**@sizan5** · 1 upvotes

> ### Why A is close — but not enough
>
> #### A) Read Replicas
>
> This is a very common production optimization.
>
> It helps because:
>
> - reporting queries move away from primary DB
> - read traffic gets distributed
> - primary DB handles fewer queries
>
> But it does NOT solve:
>
> - expensive aggregations
> - heavy joins
> - analytical scan workloads
> - replica lag under high load
>
> Eventually, reporting queries simply crush the replicas instead of the primary.
>
> Read replicas are a scaling tactic.
> A warehouse is a workload isolation strategy.
>
> That distinction matters.

**@sizan5** · 1 upvotes

> ### Why B helps temporarily — but misses the root problem
>
> #### B) Redis Cache
>
> Caching absolutely reduces load.
>
> Great for:
>
> - repeated dashboard requests
> - hot metrics
> - frequently accessed reports
>
> But caching breaks down when:
>
> - users need fresh data
> - filters become dynamic
> - reports are generated ad hoc
> - cache invalidation gets complex
>
> Redis reduces repeated reads.
> It does not separate analytical workloads from transactional systems.
>
> This becomes a band-aid, not an architecture.

---

[View this post on daily.dev](https://daily.dev/posts/day-1-style-system-design-question-08pqx7fqm)