System designHard~20 minSystem Design Foundations Essentials / 15 of 15

Interview question

Design a backend feature where users see live status updates, comments, or dashboard changes without refreshing the page.

Design real-time live updates

Designs live updates with polling, server-sent events, or WebSockets while preserving authorization, ordering, scale, and fallback behavior.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would start by choosing the simplest transport that meets the requirement. Polling may be enough for low-frequency updates, server-sent events can stream one-way updates, and WebSockets fit bidirectional interaction. The backend would authorize each subscription, publish events when relevant state changes, and let clients fetch the latest state after connecting so missed messages do not leave the UI wrong.

Full answer below

Practice focus

Realtime transport choices, subscription authorization, fan-out, ordering, reconnect behavior, backpressure, and fallback design.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Live updates are product-visible, but the hard part is backend boundaries. The system must decide what is pushed, who can subscribe, how reconnection works, and what happens when realtime delivery falls behind.
I would start by choosing the simplest transport that meets the requirement. Polling may be enough for low-frequency updates, server-sent events can stream one-way updates, and WebSockets fit bidirectional interaction. The backend would authorize each subscription, publish events when relevant state changes, and let clients fetch the latest state after connecting so missed messages do not leave the UI wrong.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would separate durable state from transient delivery. The database or read model remains the source of truth, while realtime messages tell clients what changed. Events need tenant or resource scope, sequence or timestamp, and enough data for the client to refetch if needed. Reconnect behavior matters: clients may resume from a cursor or simply reload the current view. For high fan-out, I would add a backplane or broker so multiple API instances can deliver consistently.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would set limits on connections, subscriptions, message size, and fan-out per tenant. Authorization must be rechecked when roles change or subscriptions target sensitive resources. Backpressure and slow clients need disconnect or downgrade behavior. I would monitor active connections, reconnect rate, delivery latency, dropped messages, broker lag, and fallback usage. If ordering is critical, the design must say where ordering is guaranteed and where clients reconcile.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Choosing WebSockets before proving polling is insufficient.
Treating pushed messages as the source of truth.
No authorization check for subscriptions.
No reconnect or missed-message behavior.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain transport trade-offs.
Leaks updates across tenants or private resources.
No plan for multiple API instances.
Slow clients can exhaust server resources.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When would polling be better than WebSockets?
How would clients recover missed messages?
How would you scale fan-out across API instances?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

2 linked

Go deeper

Practice the next layer of the same subject.

Activity Feed Dashboard Read Model

Opening drill

System designHard~20 minSystem Design Foundations Essentials / 15 of 15

Interview question

Design a backend feature where users see live status updates, comments, or dashboard changes without refreshing the page.

Design real-time live updates

Designs live updates with polling, server-sent events, or WebSockets while preserving authorization, ordering, scale, and fallback behavior.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Realtime transport choices, subscription authorization, fan-out, ordering, reconnect behavior, backpressure, and fallback design.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Live updates are product-visible, but the hard part is backend boundaries. The system must decide what is pushed, who can subscribe, how reconnection works, and what happens when realtime delivery falls behind.
I would start by choosing the simplest transport that meets the requirement. Polling may be enough for low-frequency updates, server-sent events can stream one-way updates, and WebSockets fit bidirectional interaction. The backend would authorize each subscription, publish events when relevant state changes, and let clients fetch the latest state after connecting so missed messages do not leave the UI wrong.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would separate durable state from transient delivery. The database or read model remains the source of truth, while realtime messages tell clients what changed. Events need tenant or resource scope, sequence or timestamp, and enough data for the client to refetch if needed. Reconnect behavior matters: clients may resume from a cursor or simply reload the current view. For high fan-out, I would add a backplane or broker so multiple API instances can deliver consistently.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would set limits on connections, subscriptions, message size, and fan-out per tenant. Authorization must be rechecked when roles change or subscriptions target sensitive resources. Backpressure and slow clients need disconnect or downgrade behavior. I would monitor active connections, reconnect rate, delivery latency, dropped messages, broker lag, and fallback usage. If ordering is critical, the design must say where ordering is guaranteed and where clients reconcile.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Choosing WebSockets before proving polling is insufficient.
Treating pushed messages as the source of truth.
No authorization check for subscriptions.
No reconnect or missed-message behavior.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain transport trade-offs.
Leaks updates across tenants or private resources.
No plan for multiple API instances.
Slow clients can exhaust server resources.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When would polling be better than WebSockets?
How would clients recover missed messages?
How would you scale fan-out across API instances?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

2 linked

Go deeper

Practice the next layer of the same subject.

Activity Feed Dashboard Read Model

Design a backend feature where users see live status updates, comments, or dashboard changes without refreshing the page.

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

Design a backend feature where users see live status updates, comments, or dashboard changes without refreshing the page.

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper