After reading hundreds of system design assignments from cohort members, three gaps show up so consistently that I now watch for them specifically in every submission.
They’re not exotic. They’re not about knowing obscure algorithms. They’re about the difference between an answer that sounds right and an answer that demonstrates you understand what you’re designing.
Gap 1: Numbers that don’t drive anything
Most cohort members can estimate. They get DAU, they calculate requests per second, they calculate storage. The numbers are usually in the right order of magnitude.
Then the next section of their answer proceeds as if the numbers never existed.
“We’ll have approximately 50,000 writes per second” followed by “I’d store user data in a Postgres database.” No mention of whether Postgres handles 50,000 writes per second. No acknowledgment that this number might matter for the technology choice.
The numbers should be the reason for the architectural decisions. Not a box checked before the real answer begins.
The fix is simple: after every estimation number, add one sentence starting with “this means.” 50,000 writes per second — this means a single Postgres instance will be the bottleneck; I’ll need to either shard or move to a write-optimized store like Cassandra. Now the number is doing work.
Gap 2: The happy path only
Most cohort submissions design a system that works when everything goes right. The API is called, the database responds, the message is delivered. The walkthrough is coherent.
Then nothing goes wrong. There are no failure modes. There’s no offline user, no database timeout, no cache failure, no duplicate message delivery.
The simplest version of this is in the messaging question: a candidate designs the delivery path for an online user but never addresses what happens when the recipient is offline. The question literally asks about this. The omission is not subtle.
The fix is one explicit section at the end of every design: “three things that break.” Name them, name the conditions, and describe how you detect and handle each. Even if the answer is “we’d accept degraded behavior and alert on it” — that’s a real answer.
Gap 3: Decisions without reasons
“I’d use Kafka for the event stream.”
Why Kafka? This sentence appears in dozens of submissions every cohort. Sometimes Kafka is the right answer. Sometimes a simple SQS queue would be better. Sometimes a database table with FOR UPDATE SKIP LOCKED is better. The choice depends entirely on the requirements.
When you state a technology choice without a reason, you’re signaling that you know the word, not the trade-off. The interviewer probes exactly here. “Why Kafka over something simpler?” is one of the most common follow-up questions in design interviews.
The fix is to never name a technology without one of these two phrases following it: “because” or “instead of.”
“I’d use Kafka because the producers and consumers have different throughput — decoupling them lets each scale independently.” Now the choice has a reason.
“I’d use Redis instead of Memcached because we need persistence and sorted sets for the leaderboard.” Now the choice has a comparison.
Why these gaps matter more than knowledge gaps
The three things above — numbers with consequences, failure modes, and reasoned decisions — are what experienced engineers do automatically when they design systems. Not because they’re trying to impress anyone. Because they’ve been on-call for systems that failed when the failure mode wasn’t anticipated, and they’ve had to defend technology choices to skeptical colleagues.
The interview is asking: does this person think like someone who has built and operated real systems?
The three gaps signal no, even when the technical knowledge is there.
If your answers have all three gaps, the fix is not more studying. It’s one mock interview where you discipline yourself to add “this means,” “three things that break,” and “instead of” to every section of your answer.
CTA: The cohort curriculum is built around closing exactly these three gaps — each module targets one of them directly.
Subscription link
https://systemdr.systemdrd.com/subscribe
—Sumedh
Curious how this works in real systems?
The paid lessons cover scalability, optimization, and real-world engineering patterns.