From 0 to 100k Users: The Scaling Decisions That Matter
Most performance problems are architecture problems in disguise. Here's the playbook we wish we'd had on our first launch.
Scaling is mostly boring. The exciting stories - the all-night war rooms, the heroic refactors - are usually evidence that something obvious was missed early. Here are the decisions that actually move the needle.
0–1k users: pick boring infrastructure
Postgres, a managed host, and a single region. Don't introduce Kafka, microservices, or Kubernetes until you have a problem that genuinely requires them.
1k–10k users: cache aggressively
Edge caching, ISR for content, Redis for session and rate-limit state. 80% of your traffic is reading the same thing.
10k–100k users: split the read path
Read replicas, queue-based writes for anything non-critical, and an honest look at which queries are doing too much work. Add an APM tool the day you cross 10k - flying blind is the most expensive thing you can do.
The decision that matters most
Hire someone whose only job is reliability before you need them. Every team we've seen burn out skipped this hire and tried to scale the on-call rotation instead.