How to build an app that scales to a million users

Decisions worth getting right early (they're cheap now)

• A clean data model with proper indexes — fixing this later is painful
• Stateless services, so you can simply run more copies when traffic grows
• Caching the expensive, frequently-read things
• Background jobs for slow work instead of making users wait
• Metrics and logging from day one, so you can see where it hurts

Things to deliberately defer

Sharding, multi-region deployments, custom infrastructure, and micro-optimisations are almost always premature for a young product. They cost real time and money, and the right design for them depends on usage patterns you won't know until you have users. Deferring them isn't laziness — it's keeping your options open until the data tells you what to do.

Where apps actually fall over

In practice, the first thing to break under load is rarely the fancy part — it's an unindexed database query, an N+1 loop, a synchronous call to a slow third party, or a single server holding session state. Good engineering anticipates these cheaply. That's why we test and profile before launch, not after the first spike takes the site down.