Realtime Backend System Design with WebSockets from Udemy

However, what’s truly more challenging is designing real-time backend applications that support unfettered and ad-hoc bidirectional communication. The workloads of gaming, chatting, and even mission-critical real-time applications are unique in that they require a “push” nature to function effectively.

I spent a few months designing this course, and I chose the WebSockets protocol as the foundation for this work. WebSockets is by far the most widely available bidirectional protocol, supported across all clients—from browsers and command-line apps to runtimes like Node and Bun, and even other languages like C and Go.

While there is the newer WebTransport protocol, it isn’t yet as widely supported or battle-tested as WebSockets. Perhaps I’ll refresh this course in a few years when WebTransport matures.

This course is divided into three main sections:

1. WebSockets Internals – A deep dive into the inner workings of the protocol: the handshake, keepalive mechanisms, frame headers, and how it behaves over TLS. We’ll also discuss limitations—because I believe understanding limitations helps us build better applications. Each lecture will include a coding session and a quiz at the end of the section.

2. Scaling WebSockets – Taking your WebSocket knowledge to the maximum: how to scale this protocol over HTTP/1.1, HTTP/2, and HTTP/3. We’ll cover implementation with proxies in both stream mode (Layer 4) and application mode (Layer 7), along with their pros and cons. Each lecture will include a coding session and a quiz at the end of the section.

3. Building Real-Time System Designs – Putting everything into practice by designing two systems: an I/O-intensive chat system and a CPU-intensive game. I’ll propose multiple designs for each and choose one to implement.

Prerequisite: Fundamentals of Backend Engineering.

I hope you enjoy the course.

What's inside

Learning objectives

System design for real-time backend scaling
The internals of websockets
How websockets work
Websockets on secure tls
Scaling websockets with layer 4 proxying

Scaling websockets with layer 7 proxying
Websockets on http/2 and http/3
Building a real-time group chatting app (io intensive)
Building a real-time game app (cpu intensive)

System design for real-time backend scaling
The internals of websockets
How websockets work
Websockets on secure tls
Scaling websockets with layer 4 proxying
Scaling websockets with layer 7 proxying
Websockets on http/2 and http/3
Building a real-time group chatting app (io intensive)
Building a real-time game app (cpu intensive)

Syllabus

Introduction

Welcome

Backend Engineers who are interested in leveling up their skills for real-time applications.

Course Outline

You can find the slides, referenced papers and source code under the resources of this lecture

If you can answer at least 8 out of 10 questions of this quiz move to next section

If we know the limitations of a protocol we can use it effectively.

This is an IO intensive , so we don't need as many backends so backends can be built in a mesh architecture.

No load balancing, client picks the server, only rooms within the server can be used. No database, very simple.

Pros, simple

Cons, can't chat with other servers, no load balancing (one server can get overloaded if the url is shared)

Load balanced at stream level, client connects to the closest gateway, fleet of backends per gateway. a pub/sub to relay messages.

Client sends a message streamed through gateway streamed through a backend, a backend writes it to the pub/sub and all backends subscribe to the pub/sub, message pushed to all backends subscribed. queue room number.

Pros: Can chat with other all rooms, load is balanced

Cons: Complex, more components, resource intensive (streaming)

WS application load balancing, h2 web sockets or even shared web sockets (less connections more streams) , gateways. Still pub/sub

Pros: Better resource usage (compare to Design 2) , load balancing

Cons: Complex more components, Backend implementation is tricky (h2)

Because we don't anticipate lots of backends. We can drop the pub/sub and have the backends talk to each other directly.

WS application load balancing, h2 web sockets or even shared web sockets (less connections more streams) , gateways.

Pros: Better resource usage (compare to Design 2) , load balancing

Cons: Less complex than Design 3, ditched the pub/sub system

Gamers join an interactive World game
Gamers interact with objects to “break”
Breaking an item gets XP based on the item
Only one gamer gets the XP (last one that destroy it)
All game World must update in real-time

CPU intensive, game need to scale

When a player make a move or attack, a ws msg is sent, the new game state is calculted and the diff is sent to all players get the new state. Or we can send the moves and have the clients calculate the state.

No load balancing, locality and lowest latency. Clients pick the server. You can only join games in the same server you connect to. Simple design. We can restrict the number of players per game and restrict players accordingly (each box can handle x concurrent games)

When a player make a move or attack, a ws msg is sent, the new game state is calculated and the diff is sent to all players get the new state. Or we can send the moves and have the clients calculate the state. The moves are labeled and ordered by arrival time.

No need for a database

Pros: Low latency

Cons: A single Server can be overloaded if too many players join

Load balancer that is game aware when a game is created it will pick a server.

Players who want to join to the same game will "land" on that server.

Pros: Scalable

Cons: Need more components, we need to see All active games, we need to a database to store games.

Career center