Revision · Scaling & Performance

This part framed scaling not as an architecture you pick up front but as a sequence of bottleneck removals: at any load exactly one resource is the binding constraint, and the job is to relieve only that one at the least added complexity. Every technique here is a trade — headroom bought with some new cost.

What this part covered

• Scale only what you must — every technique adds complexity, a permanent tax on debugging and on-call; the goal is enough headroom for the next 6–18 months, not maximum scalability.
• Vertical vs horizontal scaling — a bigger box is simple but hits a ceiling; more boxes is near-unlimited but trades that simplicity for the complexity of coordinating a fleet.
• Statelessness & sessions — horizontal scaling only works if app servers hold no local state, so session state moves out to sticky sessions, a central store like Redis, or stateless JWT tokens.
• Caching strategies — the highest-leverage latency move, spanning cache-aside, read-through, and the write patterns (through, back, around) — with invalidation as the famously hard problem inside.
• Read replicas & CQRS — copy data to scale reads, paying with replication lag that breaks read-your-writes; split the read and write models with CQRS only when the payoff is real.
• Database scaling patterns — the database is almost always the first wall, climbed in a ladder: bigger box, read replicas, caching, functional partitioning, then sharding with its cross-shard pain.
• Finding performance bottlenecks — the meta-skill and the diagnosis behind every cure: measure before optimizing with the USE method, and hunt the usual culprits like the database, N+1 queries, lock contention, and chatty calls.

The takeaway

Bottlenecks move — relieve one constraint and the load flows to the next-weakest link, which is the expected shape of scaling, not a design failure. Because every cure applied to the wrong organ does nothing but add complexity, diagnosis comes first: measure which wall you are actually hitting, then knock down that one. And keep the constraints from earlier parts in view — you cannot scale faster than consistency, coordination, and the speed of light allow.