What they're testing
Whether you can handle an open question. The prompt is deliberately vague — drawing immediately already loses points.
The short answer~30 seconds
Four minutes clarifying: who uses it, which features are in scope, and what's explicitly out. Then estimate the numbers: active users, read/write ratio, data size — because the numbers decide the design. Only then trace one request end to end, design the data model, and after that discuss scaling. Save five minutes for failure: what breaks first, and how you'd find out.
The long answer
Clarification scores highly because it simulates the actual job: nobody hands you a complete spec. Good questions sound mundane — "do we support editing after posting?", "is old data retained forever?" — and each one prunes a large branch of the design. The interviewer usually has constraints in mind and is waiting for you to surface them.
On estimation, precision isn't required — the right order of magnitude is. A million daily actives at ten actions each is 10M events a day, over 86,400 seconds that's about 120/sec average, with peaks typically 3–5×. That number immediately says this is NOT a Kafka problem. Many candidates skip this step and design for a hundred times the actual scale.
The failure discussion is what separates junior from senior most clearly. Anyone can draw the happy path. Saying "if the cache dies the database takes ten times the traffic, so we need a circuit breaker and a concurrency cap" is an entirely different signal. If time is running out, raise it deliberately rather than letting it drop.
What they'll ask next
?What if you don't know a component?
Say so, then describe it in terms you do know: "I haven't run Cassandra, but what I need here is high write throughput with partition-key access — if Cassandra gives that, it fits". That still scores; bluffing terminology costs twice as much.
These lose points
- Drawing boxes and arrows in the first two minutes. You're answering a question nobody has asked yet.
- Filling the diagram with every technology you can name. Every box you draw is a box you must defend.