Messages Other People Send

Team 4 sits together in the lab. Priya and Marcus both have the team’s room open. Priya posts the link to the team’s design doc.

With the API we have, how does Marcus see Priya’s message?

Request and response

Marcus’s client sent its last request when Marcus opened the room, and that request already has its response. So Marcus does not see Priya’s message unless Marcus’s client sends another request. In HTTP, the client sends a request and the server sends a response. The server never sends anything that was not a response to a request.

sequenceDiagram
    participant P as Priya's client
    participant S as Server
    participant M as Marcus's client
    M->>S: GET /rooms/12/messages?limit=50
    S-->>M: 200, the latest 50 messages
    P->>S: POST /rooms/12/messages
    S-->>P: 201, Priya's message
    Note over S,M: Marcus's client has no request waiting, so nothing reaches Marcus

Marcus could reload the page, and the client would send a new request. But the requirements say a member with the room open must see a new message without reloading the page.

Real-time

Chat needs the server to send new data to a client that did not send a request for it. The data also has to get there soon.

Real-time, as we use it, means soon enough that a person does not notice the delay. Our target is the latency requirement: a new message appears on the screens of the room’s other members within one second.

This is the everyday meaning of real-time. Engineers also use the term for hard real-time systems, such as the controller in a car’s brakes. When the driver presses the pedal, the controller must act within a few milliseconds. If it is late even once, the system has failed. Chat is different. If one message takes two seconds to show up, that is annoying, but the system has not failed. This course does not cover hard real-time systems.