Case Study: Scaling a Web App Step by Step

Grow the architecture with the traffic

Systems rarely need their final architecture on day one. A common path: Stage 1, one server running the app and database; fine for a prototype. Stage 2, move the database to its own managed instance with backups and point-in-time recovery; add monitoring. Stage 3, put a load balancer in front of two or more stateless app instances across zones; sessions move to Redis; static files move to object storage and a CDN. Stage 4, add an application cache and database read replicas for read-heavy pages; move slow work to queues and workers. Stage 5, introduce SLOs, autoscaling, canary deployments and on-call. Stage 6, as write volume or data size outgrows one primary, partition data or split specific domains into separate services with their own stores. Stage 7, multi-region only if users or availability targets require it. At every stage, measure first and fix the current bottleneck rather than the imagined one.

Bottleneck-driven growth

Each change is triggered by a measured symptom.

symptom                                        change
---------------------------------------------  --------------------------------------------
app and DB fight for CPU on one box            separate managed database
one app server at 80% CPU, no redundancy       LB + 2-3 stateless instances across zones
same product pages read 1000x per minute       cache + CDN; read replicas
uploads and emails slow down requests          queue + workers
releases cause outages                         canaries, feature flags, SLO alerts
single primary saturated on writes             partition by customer / split a domain
users on another continent see 300 ms+ RTT     edge caching first, then a second region

Extending a house

You add a room when the family grows, not before you are married. But you lay foundations strong enough for a second floor (stateless app servers, backups, monitoring) from the start, because they are hard to add later.

त्वरित जाँच: Product pages are read thousands of times per minute and the primary database is busy. What is usually the first step?

• Shard the database by product ID
• Add caching (and a CDN) and serve reads from replicas
• Move to multi-region active-active
• Rewrite the app in another language