LLM prompts are the new thing in system design rounds, but read actual loop debriefs and a quieter truth emerges: most rejections still come from fumbled fundamentals. The candidate who couldn't say when they'd use a queue. The one who added Redis without saying what happens on a miss storm. The one who chose strong consistency everywhere because it sounded safe. Classic distributed systems remain the core of the round, and the AI questions are usually these same fundamentals in a new outfit.
Here's the depth the classics actually get graded at in 2026.
Queues: know why, not just where
Everyone puts a queue in the diagram. The follow-ups test whether you know what you bought (decoupling producer from consumer speed, absorbing spikes, retry with backoff) and what you paid: eventual processing, ordering questions, and a new failure mode called "the queue is backing up." Be ready for three questions in particular. What happens when the consumer is down for an hour? The queue grows, so know your retention and your drain rate. Can a message be processed twice? Yes, so consumers must be idempotent, and you should say that word. Does order matter here? If it does, you need partitioning by key, and you should say which key.
Caches: the miss is the interview
Adding a cache is free. The grading is on the miss path and the invalidation story. Have crisp answers for what hit rate you're assuming and what happens at 0% (cold start after a restart — can the database survive it? if not, say "request coalescing" or "warm-up"). Know how data gets invalidated: TTL for tolerable staleness, explicit invalidation for correctness-critical data, chosen per data type and out loud. And know the stampede: a hot key expires and a thousand requests hit the database at once. Naming that problem unprompted, with a fix like stale-while-revalidate or per-key locks, is one of the strongest fundamentals signals you can send.
Consistency: choose per data type, not per system
"I'd use strong consistency" as a blanket answer lowers your level. So does a reflexive "eventual consistency scales better." What gets graded is segmenting: this system's payment state needs linearizability, its view counters don't, its user profiles need read-your-own-writes and nothing more. Then attach the mechanism. A single-writer relational core for the money, async replication for the rest. Interviewers report this one habit, consistency chosen per data type with reasons, as a reliable senior/mid discriminator.
Sharding and hot spots
Know your partition key and your celebrity problem. Any "design a social/chat/feed system" prompt eventually reaches: one user has 100M followers, what breaks? Have the toolkit ready. Partition by a key with even distribution, detect hot keys, and special-case the head of the distribution with a dedicated cache or fan-out on read for celebrities instead of fan-out on write.
Why this still decides loops
Frameworks and vendors abstract these topics in daily work, which is exactly why interviews target them: they're checking the model in your head, not your ability to configure a managed service. The good news is the list is short. Queues, caches, consistency, partitioning, replication, plus the failure modes of each. Depth on those five beats surface familiarity with fifty technologies, in 2026 as in every previous year.