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.

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.

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

Technologies

Tech stacks

Skill areas

Suggest an improvement