A simple model, honestly explained.
The simulator is built to give intuition about bottlenecks and trade-offs, not to size production hardware. Every number you see comes from the rules below.
Capacities and costs
| Component | Capacity | Cost |
|---|---|---|
| Load balancer | 50,000 req/s | $20/mo |
| App server (each) | 400 req/s (6 workers × 15 ms) | $40/mo |
| Cache | 50,000 ops/s | $30/mo |
| Database / replica (each) | 1,250 queries/s (10 workers × 8 ms) | $120/mo |
| Async write queue | 30,000 msgs/s | $25/mo |
| CDN | Unlimited for static files | $15/mo (excl. bandwidth) |
The rules
- Each component is a pool of parallel workers (an M/M/c queue). Waiting time uses the Sakasegawa approximation, so latency stays flat until about 80% utilization and then climbs steeply, like real servers.
- Requests follow real paths: static files (via CDN or app servers), cache hits, cache misses (cache-aside: app → cache → back to app → database), synchronous writes and async writes.
- Overload sheds the excess immediately (an HTTP 503). A component at 200% of capacity rejects half of what reaches it. Only requests whose path goes through that component fail.
- p95 latency is measured, not averaged: 5,000 requests are simulated across the paths and the 95th percentile is reported. It is server-side time and excludes network round trips.
- Read replicas share reads with the primary in proportion to spare capacity. Every replica also applies every write (log replay, about 40% of a write's cost). If a replica can't keep up, replication lag grows forever and the design fails.
- An async write queue acknowledges writes fast but adds no database capacity. If the primary can't keep up on average, the backlog grows forever: those writes were acknowledged but never stored.
- Headroom: a design is called healthy only if every component stays below 90% utilization, p95 stays under the target and errors stay under 1%.
- Steady peak traffic: the model looks at a sustained peak, not bursts. One database query per request is assumed. Costs exclude bandwidth.
Not modelled (yet)
Sharding, rate limiting, autoscaling, retries and retry storms, multiple regions and network latency, cache size versus hit rate, replication lag on reads, and circuit breakers.