Scenario / Database scaling

Database Scaling Strategies: Read Replicas Under Live Traffic

A financial ledger app where the single database becomes the ceiling. Read replicas, connection pool tuning, and query offloading are the only paths forward.

Run this scenario

Briefing

Database scaling strategies

Database scaling separates read pressure, write pressure, and connection pressure instead of treating the database as one generic box.

Read-heavy systems can scale with replicas and caches, while write-heavy systems eventually need deeper architecture changes.

You can scale reads with replicas and caches. Writes remain the hard limit.

  • Use cache for repeated reads before they reach storage.
  • Use replicas for read-only traffic, not primary writes.
  • Watch connection pool pressure separately from raw database load.

Contract

Uptime

99.8%

P95 latency

160ms

Budget

$620/mo

Traffic shape

Morning surge that tests capacity during a narrow peak. Baseline 200 users; peak around 2,800 users over 48 hours.

Available components

Server

HTTP request handler Every web app needs at least one server. More servers let you handle more simultaneous requests before latency starts climbing.

Postgres

Primary data store Without a database, your app has no memory. Most dynamic requests eventually depend on it.

Redis

In-memory cache layer Popular pages, profiles, and product data often get requested again and again. Serving those from memory is much faster and cheaper.

LB

Load balancer If you run more than one server, something needs to decide where each request goes. That is the load balancer.

Replica

Read-only DB copy Many applications read far more often than they write. Replicas let you spread those reads across more machines.

Queue

Async job buffer Moving background work out of the request path keeps the app responsive even when extra processing is needed.

Worker

Background job processor Separating background work keeps checkout, page loads, and other user actions from competing with batch processing.

Common mistakes

  • Connection pools can fail before raw database capacity reaches 100%.
  • Query-heavy paths need indexes, replicas, or search offload before peak traffic.
  • Replicas help only when lag, write volume, and retry behavior are controlled.
  • Migrations must be designed as production traffic events.

Interview adjacency

  • Scale a read-heavy app
  • Design a financial ledger
  • Explain read replicas