// System Design · 01
Scalability
The ability to handle growth without falling over.
How it fits together
- Users uses / calls Load balancer (requests)
- Load balancer uses / calls App instance 1
- Load balancer uses / calls App instance 2
- Load balancer uses / calls App instance 3
- App instance 1 uses / calls Session store (session state)
- App instance 2 uses / calls Session store
- App instance 3 uses / calls Session store
Spot it
- Response times climb as traffic climbs
- Peak hours need manual babysitting
- Adding users means adding incidents
It costs
More moving parts, and state becomes something you have to place deliberately.
Go deeperThe full explanation and what to ask for · 1 min readExpandCollapse
Scalability is not speed. A fast system that collapses at twice the load is not scalable; a slower one that degrades gracefully at ten times the load is.
It comes in dimensions: load (requests per second), data (how much you store), and organisation (how many teams can work on it). Most designs only plan for the first.
The usual path is: remove state from the compute tier, cache what is read often, replicate reads, then partition writes. Each step buys roughly an order of magnitude and costs complexity.
Ask for it
- stateless services
- load balancer
- autoscaling
- read replicas
- sharding
- caching
Make this service stateless so it can scale horizontally behind a load balancer: move session state to a shared cache such as Redis, add a health check endpoint, and autoscale on CPU and request queue depth.