Scenario / Scaling reads
Guided System Design Lesson: Read Replicas
A catalog app has cache, but read volume still exceeds what the primary database should answer alone.
Run this scenarioBriefing
Read replicas
Replicas scale reads; the primary still owns every write.
Replicas scale reads; the primary still owns every write.
Replicas scale reads; the primary still owns every write.
- Watch read replicas in the simulator.
- Watch primary writes in the simulator.
- Watch database pressure in the simulator.
Contract
95%
280ms
$620/mo
Traffic shape
Daily traffic curve with a predictable high-traffic window. Baseline 340 users; peak around 2,300 users over 28 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.
LB
Load balancer If you run more than one server, something needs to decide where each request goes. That is the load balancer.
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.
Replica
Read-only DB copy Many applications read far more often than they write. Replicas let you spread those reads across more machines.
Common mistakes
- Adding capacity after the bottleneck has already saturated.
Interview adjacency
- Scale database reads
- Explain primary and replica roles
- Design a catalog service