At a glance
- Did you know
- Postgres runs one process per connection, which is why poolers like PgBouncer sit in front of busy databases.
- Rule of thumb
- Read replicas scale reads, not writes, and can serve slightly stale data.
- Watch out
- Pool exhaustion, CPU saturation, lost updates and stale replica reads.
Problems that start with it
- Read-heavy product catalog 2,000 req/s, 90% reads through a cache. At 20 s the cache is flushed.
- Slow database rescue The database answers reads in 9 seconds. The API gives up after 5 seconds and retries twice.
- Edge defence: survive a DDoS 1,500 req/s of real users. At 15 s a 20,000 req/s flood hits for 15 s. Nothing stands in front of the load balancer.
- YouTube end to end 20,000 requests/s routed by path: watch, search, comments and uploads. Metadata cache in front of Vitess MySQL, recommendations, view events into Kafka, uploads to storage and a transcoding queue.
- One server on launch day Your startup runs on a single API server behind a load balancer. Launch-day traffic is 1,500 requests a second.
- Black Friday spike A shop handles 1,500 req/s comfortably. At 10 s, Black Friday traffic triples for 15 seconds.
- CPU-bound API The API renders pages on the server: 6 ms of CPU per request on 2 vCPUs per replica, at 1,500 req/s.
- Database out of CPU Every read and write goes to one Postgres with 2 vCPUs, at 2,000 req/s. There is no cache.
And 108 more on the problems page.
Full lesson coming soon
Lessons are being added one component at a time: how it works, its settings, a live exercise to break and fix it, interview questions and a short check. See the Circuit breaker lesson for what one looks like.