1. Realtime communication

Picture the order-tracking screen in a food-delivery app. The customer has paid, and over the next half hour the order moves from confirmed to preparing to picked up while a marker slides along a map. Every endpoint you designed for that app answers a request the client made, and that is the problem: the client cannot ask for a change it does not know happened.

Realtime communication is the set of arrangements that get a server's state changes to a client without the client asking for each one. It covers how the update travels and what keeping that path open costs the server, and it stops there.

In an interview, realtime communication usually comes up after the components and API are clear: how does the client learn that something changed? Chat, notifications, dashboards, and tracking surfaces all need an answer. The common mistake is choosing WebSocket by default without first checking the direction, update frequency, or behavior after a dropped connection.

At mid-level, identify the four options and justify one for the feature at hand. A senior answer must also account for connection capacity, dropped connections, and routing each event to the instance that holds the relevant client connection.