Real-time Updates

Learn about methods for triggering real-time updates in your system design

Intro

In many products, its helpful to get real-time updates from the system as things happen or as data changes. From chat applications where messages need to be delivered immediately to live dashboards that show you what's going on in real-time, users expect to be notified as soon as something happens.

There's two hops we have to be concerned with to make this happen: the connection between the client and the server, and the connection between the server and the data or events.

Two Hops for Real-time Updates

How this happens is an important part of system design - facilitating these real-time updates can have significant implications for your overall architecture and is often the source of interesting deep-dive interview questions (Uber, Live Comments, Whatsapp, Google Docs, etc.). For mid-level engineers, this is frequently a bonus and will help set you apart from other candidates. For staff level engineers, some familiarity is expected.

In this deep dive, we'll cover the different methods for facilitating real-time updates in your system design. We'll start by giving a bit of background about the networking concepts that make real-time updates possible (you can skip this if you're already familiar!). We'll then dive into the first hop, with different protocols for facilitating connections from servers to clients with pros and cons that come up in an interview. Finally, we'll address the second hop: the push/pull issues you'll need to address on the server side.

Let's go!

Networking 101

Before diving into the different protocols for facilitating real-time updates, it's helpful to understand a bit about how networking works — in some sense the problems we're talking about here are just networking problems! Networks are built on a layered architecture (the so-called "OSI model") which greatly simplifies the world for us application developers who sit on top of it.

Networking Layers

In networks, each layer builds on the abstractions of the previous one. This way, when you're requesting a webpage, you don't need to know which voltages represent a 1 or a 0 on the network wire - you just need to know how to use the next layer down the stack. While the full networking stack is fascinating, there are three key layers that come up most often in system design interviews:

Network Layer (Layer 3): At this layer is IP, the protocol that handles routing and addressing. It's responsible for breaking the data into packets, handling packet forwarding between networks, and providing best-effort delivery to any destination IP address on the network. However, there are no guarantees: packets can get lost, duplicated, or reordered along the way.
Transport Layer (Layer 4): At this layer, we have TCP and UDP, which provide end-to-end communication services:
- TCP is a connection-oriented protocol: before you can send data, you need to establish a connection with the other side. Once the connection is established, it ensures that the data is delivered correctly and in order. This is a great guarantee to have but it also means that TCP connections take time to establish, resources to maintain, and bandwidth to use.
- UDP is a connectionless protocol: you can send data to any other IP address on the network without any prior setup. It does not ensure that the data is delivered correctly or in order. Spray and pray!
Application Layer (Layer 7): At the final layer are the application protocols like DNS, HTTP, Websockets, WebRTC. These are common protocols that build on top of TCP to provide a layer of abstraction for different types of data typically associated with web applications. We'll get into them in a bit!

These layers work together to enable all our network communications. To see how they interact in practice, let's walk through a concrete example of how a simple web request works.

Request Lifecycle

When you type a URL into your browser, several layers of networking protocols spring into action. Let's break down how these layers work together to retrieve a simple web page over HTTP. First, we use DNS to convert a human-readable domain name like hellointerview.com into an IP address like 32.42.52.62. Then, a series of carefully orchestrated steps begins:

Simple HTTP Request

DNS technically can run over TCP or UDP, but we'll exclude that for simplicity in this illustration. ↩
We use SSE extensively for Hello Interview and the amount of time we've spent dealing with networking edge cases is mind boggling. ↩

Purchase Premium to Access

This article is only available to Premium users.

Purchase Premium

Next: Introduction

Deep Dives