💳 Payments system design
A simplified, healthy design: 4 app servers behind a load balancer, 1 read replica, a primary database. At 800 requests per second it runs at p95 61 ms with 0.0% errors for about $420/month.
Healthy at 800 req/s
- p95 latency (server)
- 61 ms
- Error rate
- 0.0%
- Est. cost / month
- $420
- excl. bandwidth
App servers
400 req/s each · $40/mo
DB read replicas
+1,250 reads/s each · also applies every write · $120/mo
Primary DB: 1,250 queries/s (1 query per request). How the numbers work
How it works
- Correctness beats speed: a payment must be recorded exactly once, before the user is told it succeeded.
- So writes go straight to the database, not through a fire-and-forget queue.
- Balance and history reads can use replicas; caching money data is avoided because stale balances are dangerous.
Add a write queue. It looks faster, but think about what "payment accepted" would now mean.
Use the Build and Traffic tabs above. The overloaded part turns red and starts dropping requests.