If you want to succeed in system design interviews for a tech role, then you’ll probably need to understand queues and pub-sub and when to use them within the context of a larger system.
Queues and pub-sub are both mechanisms that allow a system to process messages asynchronously, which basically allows the sender and receiver of a message to work independently, by providing a “middleman”. This can eliminate bottlenecks and help the system to operate more efficiently.
This is a simplified explanation, so to fill in the gaps we’ve put together the below guide that will walk you through queues and pub-sub and how you should approach them during a system design interview. Here’s what we’ll cover:
- Messaging-oriented middleware
- Message queues
- Pub-sub
- Which to use
- Example queues and pub-sub questions
- System design interview preparation
Practice 1-to-1 with ex-FAANG system design interviewers
1. Messaging-oriented middleware
1.1 What is middleware
We’re here to talk about message queues and pub-sub. But before we get into the details of those two patterns, we need some context on where they fit into a system. Central to this is the concept of middleware - a system layer that provides commonly-needed functionality as a service so that developers can focus on key functional or logical system components.
Middleware can be just a portion of the code or an entire server cluster. The sorts of common intermediary functions middleware provide include translation, transaction processing, metrics monitoring, and message passing.
1.2 Messaging-oriented middleware
Any complex system will have different components, possibly running entirely different hardware and software, that need to be able to communicate with each other. Messaging-oriented middleware (MOM) enables this communication, much like the post office enables people to send each other letters. Producers hand off packets of data called messages to the MOM which makes sure it’s delivered to the correct consumers.
Message passing allows components to communicate asynchronously. In other words, a producer can send messages independently of the state of the consumer. If the consumer is too busy or offline, a MOM will make sure the messages are delivered once the consumer becomes available again.
Asynchronicity enables system components to be decoupled from each other. This adds resilience because, when one component fails, the others can continue functioning normally. It also adds data integrity because successful message passing isn’t dependent on the producer and consumer being responsive at the same time.
The software that implements a MOM can be called a message broker. Message brokers may implement just one, or several different kinds of message passing including both queues and pub-sub. Let’s take a look at how queues and pub-sub work.
2. Message queues
Message queues are a kind of messaging-oriented middleware where producers push new messages to a named First-In, First-Out (FIFO) queue, which consumers can then pull from.
Message queues are also called point-to-point messaging because there is a one-to-one relationship between a message’s producer and consumer. There can be many producers and consumers using the same queue, but any particular message will only have one producer and one consumer.
Different queue implementations will vary in how much space the queue has, whether or not messages are batched, and how long a message is kept for if it isn’t consumed.
2.1 Message queue example
Now let’s go over a simple example of a message queue. Imagine a website that sells a high volume of T-shirts. Customers make online orders for a T-shirt and the web server produces corresponding order requests and places them on a queue for processing in the backend.
Depending on demand and availability, there could be one or several computers working to fulfill the orders. More order fulfillment servers might be needed if it’s a peak demand time of year, or if the fulfillment process for some orders is more complex.
Each order only needs to be processed once, so only one of the order fulfillment servers needs to take the order request off the queue. If for some reason multiple fulfillment servers got a copy of an order, that order would be mistakenly fulfilled multiple times.
In summary, using a queue enables the order-taking and order-fulfilling logic to be separated, and ensures that each order will be fulfilled exactly once.
3. Pub-sub
The publish-subscribe pattern, also called pub-sub, is a kind of messaging-oriented middleware that pushes a producer’s newly “published” messages based on a “subscription” of the consumer’s preferences.
There is a one-to-many relationship between publishers and subscribers, meaning any number of subscribers can get a copy of a message, but there’s only one publisher of that message. Pub-sub doesn’t guarantee message order, just that consumers will only see messages that they’ve subscribed to.
Subscriptions can be filtered by both topic and content. Topics are any category defined by the publisher, and content is any category defined by a subscriber. It’s up to the message broker to accept and manage these filters properly.
3.1 Pub-sub example
Many social networks already use parts of the pub-sub model and call it “following” users. Let’s look at an example to build a better intuition. Imagine a simple social network allows people to share recipes, follow their friends, and see a timeline of their friends' recipes.
When a user shares a recipe, they can put it in a topic. One user might categorize by what meal it is, another user might categorize by the season of the ingredients. When a user follows another user, they are subscribing to the recipes their friend publishes.
Followers can choose to see everything that’s published, or only some topics that they’re interested in. Followers can also add their own content filters, like excluding recipes that use certain ingredients.
Users can follow as many other users as they want, so their timeline will be full of recipes from many users, but each recipe only comes from one publishing user. Similarly, a user can be followed by many other users, and all of the followers will see a copy of the recipe on their timeline.
4. Which to use
Whether to use queues or pub-sub depends mostly on how many message consumers the system has. If a message needs to have only one consumer, then the message queue is the right approach. If a message needs to have possibly many consumers that get a copy, the pub-sub approach is best.
Implementations also differ in the particular message-passing guarantees they provide. Some feature variations to note are:
- Persistence: the messages are saved to persistent storage so they can be recovered in case the message broker itself goes down.
- Replays: the messages are stored even after they are consumed so a service can “replay” the message stream in failure cases to recover properly.
- Ordering: the messages always arrive to the consumer in a particular order.
5. Example queues and pub-sub 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 queues or pub-sub.
However, you may be asked to solve a problem where queues or pub-sub will be an important part of the solution. As a result, what you really need to know is WHEN (or IF) you should bring it up and how you should approach it.
To help you with this, we’ve compiled the below list of sample system design questions. Queues or pub-sub are relevant for all of the below questions.
- Design Dropbox (Read the answer)
- Design a web crawler (Read the answer)
- Design Twitter (Read the answer)
6. System design interview preparation
Queues and pub-sub are just one piece of system design. And to succeed on system design interviews, you’ll need to familiarize yourself with a few other concepts and 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:
- Network protocols and proxies
- Databases
- Latency, throughput, and availability
- Load balancing
- Leader election
- Caching
- Sharding
- Polling, SSE, and WebSockets
- Queues and pub-sub
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.
