Advice > Software engineering

Polling, server sent events, and WebSockets: system design interview concepts (8 of 9)

By Gabriela Brown on February 10, 2021 How we wrote this article
polling, streaming and sockets system design interview

Polling, websockets, and server sent events are all techniques for streaming high volumes of data to or from a server. It’s important to know the difference when designing a system, and these techniques can also come up in system design interviews.

Below, we’ll briefly define polling, SSE, and WebSockets and then we’ll dig into the essential details that you’ll need to know about each one. Here’s what we’ll cover:

  1. Purpose of polling, SSE, and WebSockets
  2. Polling
  3. Server sent events
  4. WebSockets
  5. Example polling, SSE, and WebSockets questions
  6. System design interview preparation
Practice 1-to-1 with ex-FAANG system design interviewers

1. Purpose of polling, SSE, and WebSockets

The internet is built on the HTTP standard for communicating data between web browsers and web servers. The client, in most cases a web browser, makes an HTTP request to the server, which sends back the appropriate response. This roundtrip is what happens when you type an address like 'http://www.example.com' into your browser, and you get a web page back.

The HTTP standard is widely supported and very functional. But when your application needs to transmit continuous information streams or real-time updates to clients, like a collaborative document editor that shows changes in real time. In cases like this, having to repeatedly make regular HTTP requests will slow things down.

That’s where polling, WebSockets, and SSE come in. These are three protocols that specifically focus on speed and memory efficiency for data streams. Which approach you’d want to use in a system depends on the use case. So, let’s  go over how each of these protocols work, and when to use them.

2. Polling

2.1 Short Polling

Short polling is the original polling protocol for clients to get regular information updates from a server. The steps of short polling are:

  • Client sends Server an HTTP request for new information.
  • Server responds with new information, or no information.
  • Client repeats the request at a set interval (e.g. 2s)

The advantages of Short polling are that it’s very simple and widely supported because it’s part of the HTTP. The downside of short polling is that it has a lot of request overhead from both sides: the client has to constantly make new requests, and the server has to handle them whether or not there’s new information. In practice if you want a polling connection, long polling is preferred to short polling. 

short polling

2.2 Long Polling

Long polling is a more efficient version of short polling. The steps of long polling are:

  • Client sends Server and HTTP request for new information
  • Server waits until there’s new information to respond (a “hanging” response)
  • Client repeats the request as soon as it gets the previous response back

long polling

Long polling cuts down the number of HTTP requests necessary to transmit the same amount of data to the client. The server has to be able to “hold” unfulfilled client requests, and handle the case where it gets new information to send, but the client hasn’t sent a new request yet.

The benefits of long polling are that it’s part of the HTTP protocol, so it’s widely supported, and it produces less traffic than short polling because it takes fewer requests. In order to support this, the server-side implementation is slightly more complex than short polling, but not nearly as complex as the other two protocols we’ll look at: Websockets and Server Sent Events.

There are a few drawbacks to long polling. In some implementations holding unfulfilled requests can take more server resources than short polling, and limit the overall number of possible connections. Also if there are multiple open requests from the same client, message ordering can’t be guaranteed, and messages can get lost.

Overall, long polling is a good strategy when you need a simple implementation for regularly updating clients with new information, like updating a dashboard every minute with new data. It won’t handle high volume data streams, and is still slowed down by the overhead of repeatedly reestablishing a connection between server and client. 

3. Server Sent Events

Server Sent Events provide a one-way connection for a server to push new data to a client, without reestablishing a connection every time. For example a social media app could use SSE to push new posts to a user feed as soon as they’re available. SSE connections follow the EventSource interface, which uses HTTP to make the underlying communications.

At a high level, the steps of SSE are:

  • Client creates a new EventSource object targeting the server
  • Server registers SSE connection
  • Server sends new data to the client
  • Client receives messages with EventSource handlers
  • Either side closes the connection
server sent events

The main benefit of SSEs is it provides an efficient one directional data stream where the client and server don’t need to constantly reestablish the connection. And SSE is fairly straightforward to implement, unlike websockets - EventSource is supported by all the browsers except IE. Luckly, IE support is a common issue so there are libraries for supporting it with polyfills.

There are a couple of drawbacks to SSEs. If your service outgrows the one-way connection model you’ll just have to switch to a different protocol like WebSockets. SSEs over HTTP (instead of HTTP/2) are also limited to 6 connections per browser, so if a user opens multiple tabs of your website the SSE won’t work after the first 6 tabs.

Overall, SSEs are great when you need a simple implementation for real-time data streams where the client doesn’t need to communicate much with the server, just receive updates. But if you expect your service to need more robust functionality like bi-directional communication, you should consider investing in an implementation of WebSockets. 

4. WebSockets

WebSockets is a two-way message passing protocol based on TCP (the protocol at Layer 4 of the OSI networking model). WebSockets are faster for data transmission than HTTP because it has less protocol overhead and operates at a lower level in the network stack. At a high level, the steps of a websocket connection are:

  • Client and Server establish a connection over HTTP and then “upgraded” using the WebSockets handshake
  • WebSockets TCP messages are transmitted in both directions over port 443 (or 80 if it’s not TLS encrypted) 
  • Either side closes the connection

WebSockets

The main advantage of WebSockets is speed: the client and server don’t have to find and reestablish their connection with each other every time a message is sent. Once the WebSockets connection is established, data can flow immediately and securely in either direction. TCP ensures that the messages will always arrive in order.

The main downside of WebSockets is it takes a good amount of initial developer work to implement. You’ll have to write your own code to support some things like automatically reconnecting. Also, since WebSockets functions over ports it can be blocked by firewalls in big institutions.

An example where WebSockets is really useful is multiplayer online gaming, where the high-quality graphics of the world need to be transmitted to distributed users with real-time state updates and tight synchronization.

Overall, WebSockets are a good choice if you know you need a fast, high-quality, bi-directional connection. But it should only be used if Polling or SSE don’t fit because it adds substantial complexity to the system and takes more upfront investment to implement.

5. Example polling, server sent events, and WebSockets system design questions

The questions asked in system design interviews tend to begin with a broad problem or goal, so it’s unlikely that you’ll get an interview question entirely about polling, SSE, and WebSockets.

However, you may be asked to solve a problem where these topics will be relevant. As a result, what you really need to know is WHEN (or IF) you should bring them up and how you should approach them.

To help you with this, we’ve compiled the below list of sample system design interview questions, where these topics are relevant. 

6. System design interview preparation

Polling, SSE, and WebSockets are important to consider when designing a system. But to succeed on system design interviews, you’ll also need to familiarize yourself with a few other concepts. And you’ll need to practice how you communicate your answers.

It’s best to take a systematic approach to make the most of your practice time, and we recommend the steps below. For extra tips, take a look at our article: 19 system design interview tips from FAANG ex-interviewers.

Otherwise, you can prepare by following the steps below.

6.1 Learn the concepts

There is a base level of knowledge required to be able to speak intelligently about system design. To help you get this foundational knowledge (or to refresh your memory), we’ve published a full series of articles like this one, which cover the primary concepts that you’ll need to know:

We’d encourage you to begin your preparation by reviewing the above concepts and by studying our system design interview prep guide, which covers a step-by-step method for answering system design questions. Once you're familiar with the basics, you should begin practicing with example questions. 

6.2 Practice by yourself or with peers

Next, you’ll want to get some practice with system design questions. You can start with the examples listed above, or with our list of 31 example questions.

We’d recommend that you start by interviewing yourself out loud. You should play both the role of the interviewer and the candidate, asking and answering questions. This will help you develop your communication skills and your process for breaking down questions.

We would also strongly recommend that you practice solving system design questions with a peer interviewing you. A great place to start is to practice with friends or family if you can.

6.3 Practice with ex-interviewers

Finally, you should also try to practice system design mock interviews with expert ex-interviewers, as they’ll be able to give you much more accurate feedback than friends and peers.

If you know someone who has experience running interviews at Facebook, Google, or another big tech company, then that's fantastic. But for most of us, it's tough to find the right connections to make this happen. And it might also be difficult to practice multiple hours with that person unless you know them really well.

Here's the good news. We've already made the connections for you. We’ve created a coaching service where you can practice system design interviews 1-on-1 with ex-interviewers from leading tech companies. Learn more and start scheduling sessions today.

 

Related articles:

50+ maps interview questions and cheat sheet
Software engineeringSep 30, 2021
50+ map interview questions and cheat sheet
50+ map interview questions, all with links to high-quality solutions, plus a map refresher and cheat sheet. Part 7 of our coding prep series to help you ace your software engineer interview.
Read more
Array interview questions
Software engineeringAug 13, 2021
50+ array questions with solutions (easy, medium, hard)
50+ array interview questions, all with links to high-quality solutions, plus an arrays refresher and cheat sheet. Part 1 of our coding prep series to help you ace your software engineer interview.
Read more
load balancing system design interview
Software engineeringFeb 14, 2023
Load balancing: system design interview concepts (4 of 9)
This guide defines load balancing, how it works, and when you should use it in a system. This is the 4th of 9 foundational system design interview concepts that we're covering on our blog.
Read more
Greedy algorithm interview questions
Software engineeringNov 29, 2021
50 greedy algorithm interview questions
50 greedy algorithm interview questions, all with links to high-quality solutions, plus an interview preparation guide. Part 6 of our algorithms questions series to help you practice for your software engineer interview.
Read more
a female FAANG candidate smiles next to a whiteboard
Software engineeringNov 15, 2023
FAANG interview questions (SWE, PM, etc) + answers
Comprehensive list of FAANG interview questions for software engineers, product managers, engineering managers, etc. With links to high-quality answers, frameworks and explanations.
Read more
person preparing for an Uber engineering manager interview
Software engineeringOct 03, 2024
Uber Engineering Manager Interview (questions, process, prep)
Complete guide to Uber engineering manager interviews. Learn more about the role, and the interview process, practice with example questions, and learn key interviewing and preparation tips.
Read more
Two men coding in a sunny office
Software engineeringNov 22, 2022
49 Amazon coding interview questions (from REAL candidates)
Everything you need to know about Amazon coding interviews, including 49 real and recent sample questions, example answers, and an answer framework.
Read more
Linked list interview questions
Software engineeringSep 06, 2021
40+ linked list questions and solutions (easy, medium, hard)
40+ linked list interview questions, all with links to high-quality solutions, plus a linked list refresher and cheat sheet. Part 3 of our coding prep series to help you ace your software engineer interview.
Read more