The 12 Scalability Traps Interviewers Look for in System Design
The Twelve Hidden Bottlenecks That Undermine Strong System Design Answers, Where Each One Appears, and How to Fix It Before the Interviewer Finds It
A system design answer can look complete and still be quietly broken.
The candidate names the right components, arranges them sensibly, and produces a diagram that seems reasonable.
On the surface, the design is fine. Then the interviewer asks how it handles ten times the traffic, and the whole thing begins to unravel, because somewhere in that reasonable-looking design sits a bottleneck that cannot scale.
This is one of the most common ways that otherwise good answers fail.
The candidate understood the components but missed the specific point where the design would strain first, and when the scale increases, that point becomes the ceiling for the entire system. A design is only as scalable as its least scalable part, and a single overlooked bottleneck caps everything, no matter how well the rest is built.
The frustrating thing is that these bottlenecks are not exotic. They are a small, recurring set of weak points that appear again and again across different designs, and interviewers know exactly where to look for them.
A candidate who does not know these points designs right past them, while a candidate who knows them can spot them in their own design and address them before the interviewer even asks.
This article walks through twelve of the most common scalability bottlenecks that break otherwise good system design answers.
For each one, it explains what the bottleneck is, why it breaks the design at scale, and how to fix it. They are grouped by where they occur, in the data layer, in traffic and load handling, and in coordination and state. The goal is to give you a mental checklist of the weak points to watch for, so your designs scale where others stall.
Why Good Designs Hit Bottlenecks
Before the list, it helps to understand why these bottlenecks appear even in careful designs, because the reason is instructive.
Most designs are built to work at the scale the candidate is imagining, which is often modest. At that scale, many components are perfectly adequate.
A single database handles the load, one instance of a service is enough, and coordination is cheap.
The design works, and it looks correct, because at the imagined scale it is correct.
The bottlenecks appear when the scale grows beyond what the candidate imagined.
A component that was fine at one level becomes the limiting factor at a higher one, and because the design was never stress-tested against that higher scale, the weak point was never noticed. The bottleneck was always there, latent, waiting for enough load to expose it.
This is why the interviewer’s favorite follow-up is to increase the scale. It is a direct test of whether the candidate can find the point that breaks first.
The twelve bottlenecks below are the points that most often break, so knowing them is knowing where to look when the scale goes up.
Bottlenecks in the Data Layer
The data layer is where scalability problems concentrate, because data is the hardest thing to distribute. Most of the worst bottlenecks live here.
1. The Single Database
The most common bottleneck of all is a single database expected to handle everything.
Early in a design, one database is natural and sufficient, but as traffic grows, that single database becomes the point where the whole system strains, since every read and write funnels through it.
This breaks the design because a single database has finite capacity for connections, reads, writes, and storage, and once traffic exceeds that capacity, the database slows down and everything depending on it slows down with it.
No amount of scaling the application servers helps, because they all still point at the one database.
The fix is to scale the database deliberately rather than treating it as limitless.
Reads are scaled by adding read replicas that serve read traffic, and writes and storage are scaled by sharding the data across multiple databases.
Caching in front of the database also relieves a large share of the read load. The key is to recognize that the database is the most likely bottleneck and to have a plan for scaling it, rather than leaving it as a single point that everything depends on.
2. The Write Bottleneck
Even after reads are scaled, writes often remain a bottleneck, because writes are much harder to distribute than reads.
Read replicas scale reads beautifully, but every write must still go through a single primary in a typical replicated setup, so the write path does not benefit from the replicas at all.
This breaks the design when write volume grows, because the single primary that handles all writes becomes saturated while the read replicas sit with spare capacity.
A candidate who adds replicas and declares the database scaled has only solved half the problem, and the write bottleneck remains.
The fix is sharding, which splits the data across multiple databases so that writes are distributed across several primaries rather than concentrated on one. Each shard handles the writes for its portion of the data, so the total write capacity grows with the number of shards.
The candidate should recognize that scaling reads and scaling writes are different problems, and that a write-heavy system needs sharding, not just replicas.
3. The Missing Cache
A design without caching, or with caching in the wrong place, sends far more traffic to the database than necessary, making the database a bottleneck long before it needs to be. Since most systems are read-heavy and much of the read traffic is repetitive, serving it all from the database wastes the database’s limited capacity.
This breaks the design at scale because the database handles a flood of repetitive reads that a cache could have absorbed, so it saturates under a load that caching would have made trivial. The bottleneck is the database, but the root cause is the absent cache.
The fix is to add caching where reads are frequent and data is relatively stable, so the common reads are served from fast memory and never reach the database.
