Inside Real-Time Systems

WebSockets, Events, and Collaborative Applications

Dhruv Kothari

Frontend Software Engineer, Postman

DY Patil College of Engineering, Akurdi, Pune

Start the talkor press

About me

Career, from college to Postman
  1. 2022GraduatedDY Patil College of Engineering
  2. 2022–24UpraisedSoftware Engineer
  3. 2024–25ZomatoSenior Software Engineer
  4. PresentPostmanSoftware Engineer

How data travels today

The client asks. The server answers.

The client is the browser or app. The server is the backend. The client makes an API call, and the server sends back the data.

The server only speaks when the client asks.

The client requests the score and the server replies
Client
Server
  1. 1 · RequestGET /score
  2. 2 · Response{ "score": "120/3" }

A live cricket score

The score changes on your screen. You did nothing. How?

  1. Does the page reload?
  2. Does it call the API every second?
  3. Or something else?
A live score card that updates on its own
IPL · Match 42Live
Mumbai176/418.2
Chennai184/720.0
Mumbai need 9 runs from 10 ballsUpdated just now

Four people, one document

Four people edit at the same time. Everyone sees every change.

A normal API call asks once and gets one answer. Here, four people send changes at the same moment.

How would you build this?

A shared trip plan with four people typing in it
Goa trip planDKNH

Trip to Goa

Day 1: flights land at 11, then the villa.

Day 2: beach morning, Fort Aguada at sunset.

Stay: a villa in Anjuna, four rooms.

Budget: ₹15,000 each, flights included.

Packing: sunscreen, chargers, ID cards.

Back: train on Sunday night.

The plan

  1. 01How data travels.TCP and UDP
  2. 02How a browser receives updates.Polling, Server-Sent Events and WebSockets
  3. 03Building a real-time chat.One-to-one, groups, and rooms
  4. 04Building a collaborative editor.Shared edits and conflicts

Real-time means updates arrive soon enough for the activity.

How data travels

Part 01TCP and UDP.

TCP

TCP (Transmission Control Protocol) is a fundamental network communication protocol that establishes a reliable, connection-oriented link between two devices to ensure data is delivered accurately and in the correct order.

Connection setup
Uses a 3-way handshake (SYN, SYN-ACK, ACK) before it sends any data.
Speed and overhead
Larger header (20–60 bytes), plus flow and congestion control. This makes it slower.
TCP resends a lost packet after its timer runs out
Sender
Receiver
  1. Packet 1
  2. ACK 1
  3. Packet 2Lost on the way
  4. No ACK. Timer runs out
  5. Packet 2, sent again
  6. ACK 2

UDP

UDP (User Datagram Protocol) is a lightweight network communication protocol that sends data directly to a destination without establishing a connection, offering maximum speed by not tracking, reordering, or resending lost packets.

Connection setup
No handshake. It sends data right away.
Speed and overhead
Small, fixed header (8 bytes) and little extra work. This makes it much faster.
Broadcast and multicast
Supported. One sender can reach many receivers.
UDP loses datagram 3 and nobody resends it
Sender
Receiver
  1. Datagram 1Received
  2. Datagram 2Received
  3. Datagram 3Lost on the wayNever knows
  4. Datagram 4Received, 3 is missing
Time

How a browser gets updates

Part 02Polling, Server-Sent Events, and WebSockets.

Short polling

The browser asks for an update at a fixed interval. The server sends the current data, even if nothing changed.

Polling intervalEffect
ShorterMore requests, less waiting
LongerFewer requests, more waiting

Hypothetical example

1,000 viewers × 1 req/s= 1,000 requests per second

Use it when updates are rare and a small delay is OK.

Short polling asks every five seconds until the score changes
Browser
Server
  1. Any new score?
  2. 120/3 · no change
  3. Wait 5 s
  4. Any new score?
  5. 120/3 · no change
  6. Wait 5 s
  7. Any new score?
  8. 124/3 · new score

Long polling

The browser asks for an update. The server waits until the data changes or a time limit ends. Then the browser asks again.

  • Sends fewer replies with no new data.
  • Keeps requests open while the server waits.
  • Needs a new request after each reply or time limit.
  • Needs code to handle lost connections.

Many requests can use the same HTTP connection.

Long polling holds the request open until the score changes
Browser
Server
  1. Any new score?
  2. Server waits until the score changesRequest stays open
  3. 124/3 · new score
  4. Any new score?
  5. Waits again

Server-Sent Events

Server-Sent Events (SSE) send text updates from the server to the browser over HTTP.

The browser opens the stream. The server sends many updates in one open response.

The browser’s EventSource API connects again by itself. To get missed events, the server must also help.

  • Score updates
  • Live announcements
  • Progress updates
One open response carries three score updates
Browser
Server
  1. GET /score/stream
    1. 120/3
    2. 124/3
    3. 125/3
    Stream stays open
  3. Close the stream

Example: AI chat streaming

You use this every day. AI chat apps like Claude and ChatGPT stream their answers.

The browser sends your question once. The server sends the answer back in small pieces, as soon as each piece is ready.

The browser does not ask again. It adds each piece to the screen.

That is why the answer appears word by word.

An AI chat answer streaming in, with the events that carry it

Explain SSE in one line.

The server keeps one response open and sends each piece as soon as it is ready.

One open response, many eventsStreaming 
data: "The server"
data: " keeps one"
data: " response open"
data: " and sends"
data: " each piece"
data: " as soon as"
data: " it is ready."

WebSockets

WebSockets is a network communication protocol that provides a full-duplex, bidirectional, long-lived connection between a client and a server over a single TCP socket.

  • Starts as a normal HTTP request.
  • The server agrees to switch to WebSocket.
  • After that, both sides can send at any time.
A WebSocket handshake, then messages both ways
Browser
Server
  1. 1 · Handshake requestUpgrade: websocket
  2. 2 · Handshake response101 Switching Protocols
  3. The TCP connection stays openData frames both ways, no HTTP headers
  4. 3 · Browser sends a message
  5. 4 · Server pushes an update
  6. 5 · Server pushes another
  7. 6 · Browser sends text
Time

Key characteristics of WebSockets

  • Bi-directional communication

    Either side can send data at any time. It does not wait for a request from the other side.

  • Persistent connection

    The connection stays open until the client or the server closes it.

  • Ultra-low overhead

    After the handshake, there are no bulky HTTP headers, which can be several kilobytes. Data goes in small text or binary frames with only 2 to 10 bytes of overhead. This cuts delay and network traffic.

  • Its own URL scheme

    Uses ws:// (not encrypted) or wss:// (encrypted) on the standard ports 80 and 443. This helps it pass through many firewalls.

Comparing the four approaches

Short pollingLong pollingServer-Sent EventsWebSockets
How it worksAsks again at a fixed intervalAsks, server waits, then asks againOne open response, server keeps sendingOne open connection, both sides send
DirectionBrowser asks, server answersBrowser asks, server answersServer to browser onlyBoth ways
ConnectionNew request each timeRequest stays open until data or timeoutStays openStays open
DelayUp to one intervalLowLowLowest
OverheadHigh: many empty repliesMedium: a request per updateLowVery low: 2 to 10 byte frames
Browser APIfetchfetchEventSourceWebSocket
Good forOrder status, dashboardsNotifications, simple chatLive scores, AI chat streamingChat, games, shared docs

Building a real-time chat

Part 03One-to-one chat, group chat, and rooms.

Two people, one server

Dhruv and Sakshi never talk directly.

Each one keeps a WebSocket open to the server. A message goes to the server first. The server relays it to the other person.

  • Solid line: sent to the server
  • Dotted line: relayed by the server
Every message between Dhruv and Sakshi goes through the server
DDhruv
Server
SSakshi
  1. Hi
  2. Hi
  3. Hello, how are you?
  4. Hello, how are you?
  5. I am good!
  6. I am good!
  7. Free this weekend?
  8. Free this weekend?
  9. Yes, let us plan.
  10. Yes, let us plan.

A group chat: the Goa trip

Four friends plan a trip. Each message goes to the server. The server sends it to everyone else in the chat.

Goa trip4 members

  1. NNishantNorth Goa or South?
  2. HHarshitNorth. Found a villa in Anjuna.
  3. KKunalTrain tickets are done.
  4. DDhruvFlights booked for Friday!
Dhruv sends one message and the server broadcasts it to the other three
1 · Dhruv sends2 · Broadcast2 · Broadcast2 · Broadcast
"Flights booked for Friday!"DDhruv
NNishant
Server
HHarshit
KKunal

Rooms: many groups, one server

A room is a group of connections. The server keeps the list.

Each message carries a room ID. The server sends it only to the people in that room.

{
  "roomId": "goa-trip",
  "from": "Dhruv",
  "text": "Flights booked!"
}

WebSocket has no rooms built in. Our app, or a library like Socket.IO, adds them.

A message for the goa-trip room reaches only that room
Server
roomId: goa-trip
  • goa-tripDNHKGets the message
  • officeARMNot sent
  • familyPSVNot sent

Building a real-time collaborative editor

Part 04Many people edit the same document, at the same time.

Many cursors, one document

Four people type in the same document at the same time.

Every key press changes the document. Every screen must show the same text, and quickly.

What should happen when Dhruv presses a key?

The shared trip plan again, four people typing
Goa trip planDKNH

Trip to Goa

Day 1: flights land at 11, then the villa.

Day 2: beach morning, Fort Aguada at sunset.

Stay: a villa in Anjuna, four rooms.

Budget: ₹15,000 each, flights included.

Packing: sunscreen, chargers, ID cards.

Back: train on Sunday night.

One edit, end to end

Send the edit, not the whole document.

  1. Dhruv types. His browser sends the edit.
  2. The server applies it and saves it.
  3. The server sends the edit to Kunal.
  4. Kunal’s screen updates.
  • Solid line: edit sent to the server
  • Dotted line: edit sent out by the server
Dhruv's edit and Kunal's edit, each applied by the server and sent to the other
DDhruv
Server
KKunal
  1. insert "North "
  2. Applies and saves
  3. insert "North "
  4. insert " in May"
  5. Applies and saves
  6. insert " in May"
  7. Both screens: “Trip to North Goa in May”

Many people, many edits

Everyone sends edits. The server sends every edit to everyone else.

The server puts the edits in one order. Then every screen applies them in that same order.

  • Solid line: edit sent to the server
  • Dotted line: edit sent out by the server

Each person gets the edits they did not make.

Four edits go to the server, and the server sends each one out to the others
insert "Day 1"DDhruv
delete line 3KKunal
Server
NNishantbold "Anjuna"
HHarshitinsert "Budget"

Two edits, one word

Dhruv and Kunal change the same word at the same moment. Both edits reach the server.

How would you resolve this conflict?

Read more: Operational Transformation (OT) and CRDTs.

Two edits to the same title reach the server at the same moment

OriginalTrip to Goa

  • DDhruvSame momentTrip to North Goa
  • KKunalSame momentTrip to South Goa
Final titleunknown

Thank you!

Any questions?

Questions about this talk?

Stuck on a part of it, or curious about how something here works? Ask me anything about it.

Send me a note

Want to grow in your career?

Book a one-on-one session for mentorship and guidance on where to go next.

Book a session on Topmate, opens in a new tab