Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

Low redirect latency (sub 1 second)
Global user base
Writes: ~100M new short URLs per day → ~1,200 writes/sec average, ~3,000/sec at peak
- 1200 QPS
Reads: ~10B redirects per day (100× writes) → ~115K reads/sec average, ~250–300K/sec at peak
- 115k QPS
URL mapping table size — short code (7 chars) + long URL (~200 bytes) + created_at + owner = ~500 bytes/row → 100M/day × 500B = 50 GB/day ≈ 18 TB/year
Growth projections — at 2× YoY growth, storage hits ~36 TB in year 2

Web servers (per region):

A stateless redirect handler (cache GET + 302) comfortably does ~10K QPS per instance
Peak ~85K QPS → ~10–12 instances + 2 spare = ~12–14 per region, behind the LB. Writes (~1K peak) add nothing meaningful on top.

Cache (per region):

At 95% hit rate, the cache sees ~80K GETs/sec at peak
One Redis primary handles ~100K QPS, but you don't want a single point of failure — run 3 shards (3 primaries + 3 replicas) so each primary does ~27K QPS and failover is safe. Total ~6 Redis nodes.

Connections:

Web → Redis: each web server keeps a pool of ~50–100 connections → 15 servers × 100 ≈ 1,500 total, ~500 per shard. Redis's default maxclients (10K) is nowhere near stressed.
Clients → web (via LB): concurrent connections ≈ QPS × latency. At 10K QPS with ~50ms end-to-end, that's ~500 concurrent active requests per server — but keep-alive inflates idle connections to a few thousand, which is still trivial for an LB + modern server.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10