A product manager asks for a "real-time" dashboard. How do you turn that into a design decision?
Show the full answer Hide the answer
What the interviewer is testing
Whether you interrogate a latency requirement rather than implementing the word.
The questions
What decision changes because the data is fresher? This is the question that settles it. If someone looks at the dashboard each morning, the answer is batch. If a decision is made within minutes and acted on, latency has value.
How often is it actually looked at? A dashboard refreshed every second and opened twice a day is paying continuously for freshness nobody consumes.
What is the acceptable staleness in seconds? Push for a number. "Real-time" usually turns out to mean "not yesterday's data", and the honest answer is frequently five to fifteen minutes.
What happens if it is wrong? Streaming aggregates drop late data by default. If the number is reported externally or reconciled, that matters and may push the design towards batch or hybrid.
The options by latency requirement
| Requirement | Design |
|---|---|
| Next day | Batch, scheduled |
| Within the hour | Micro-batch every 15 minutes |
| Within minutes | Micro-batch every 1–5 minutes — captures most of the benefit at a fraction of the complexity |
| Sub-minute, driving automated action | Streaming with a real-time serving store |
Micro-batch is the under-considered option and covers a large share of what gets specified as real-time: dramatically simpler operations, straightforward reprocessing, conventional testing.
The cost to make visible
Streaming costs more than its infrastructure: harder to test, harder to correct after a defect, and it requires the team to understand event time, watermarks, state and ordering. That capability requirement is a real constraint and belongs in the conversation.
What a strong answer adds
Offering the cheap path first — build it micro-batch, measure whether anyone needs it faster, and upgrade if they do. That is far easier than starting with streaming and discovering the complexity was unnecessary.
Common weak answers
Building streaming because it was requested. Refusing on cost grounds without establishing the actual requirement.