Scaling to 100k Users by Alex Pareto is one of the better introductory resources on web application scaling. It’s concise, concrete, and walks through the progression in a logical order: single server, separate database, caching, load balancing, CDN, read replicas.
Many startups have been there; what feels like legions of new users are signing up for accounts every day and the engineering team is scrambling to keep things running.
What the article does well Link to heading
The article’s strength is that it shows why each architectural change happens, not just what it is. You don’t add a CDN because CDNs are cool; you add one because your users in Sydney are waiting 400ms for assets hosted in Virginia. You don’t add read replicas because read replicas are on a checklist; you add them because your single database is spending 90% of its time on reads and 10% on writes, and horizontal read scaling is cheaper than vertical scaling at that ratio.
The progression is realistic for most web applications: most things that need to scale past a single server will follow a similar arc, with the exact steps depending on where the bottleneck actually is.
What’s missing (by design) Link to heading
Scaling guides like this one necessarily omit the harder problems: what happens when your data model doesn’t fit neatly into a single relational database, how you handle stateful services, where service meshes and distributed tracing come in, and, critically, how you identify where your actual bottleneck is before throwing infrastructure at it.
The answer to “what does a 100k user architecture look like?” is always “it depends on your read/write ratio, latency requirements, data consistency needs, and budget.” The article is a useful mental model for the general shape of the solution, not a blueprint.
If you’re thinking about scaling, this article is a good starting point; then instrument your application, find your actual bottleneck, and solve that specific problem.