Requirements and the Single-Server Limit

Why this matters: the single-server queue is not a strawman. It is what a queue is in one process, and understanding exactly which four properties break when you distribute it gives you the agenda for the whole design.

Key takeaway

A distributed messaging queue stores data across multiple machines. Functionally it needs five operations; non-functionally it needs durability, scalability, availability, and performance — and a single-server queue delivers none of them.

Functional requirements

Clients must be able to:

Operation	Detail
Queue creation	Create a queue and define parameters such as queue name, queue size, and maximum message size
Send message	Producers send messages to a designated queue
Receive message	Consumers retrieve messages from their designated queues
Delete message	Consumers delete a message from the queue after successfully processing it
Queue deletion	Clients delete a specific queue

Non-functional requirements

Requirement	Detail
Durability	Data must persist once received. Since producers and consumers fail independently, the queue must ensure data availability for dependent entities
Scalability	Handle load variations — changes in the number of queues, producers, consumers, and messages. Must automatically scale resources up or down
Availability	Remain operational for sending and receiving messages even if individual components fail
Performance	High throughput and low latency

Availability when nodes fail

"How can availability be maintained in a distributed messaging queue when some nodes fail?"

The mechanisms are the ones this design assembles over the next several lessons: replicate queue data across nodes so a failure does not take the only copy, keep frontend servers stateless so any one of them can serve any request, put load balancers in front to route around failed hosts, and give the cluster manager responsibility for detecting failure and reassigning ownership to a healthy node.

The single-server messaging queue

Start with how a queue works on one machine. When producers and consumers reside on the same node, they access the queue using a locking mechanism to prevent data inconsistency. The queue acts as a critical section, allowing only one entity to access data at a time.

Four drawbacks:

Drawback	Cause
High latency	Producers and consumers acquire a lock to access shared state. Under high concurrency this becomes a bottleneck — request latency rises and throughput declines
Low availability	No replication, so producer and consumer processes cannot access the queue in the event of failure
Lack of durability	No replication, so data may be lost in the event of a system failure
Scalability	Handles only a limited number of messages, producers, and consumers

Single-server queues introduce a single point of failure — if the host or network link fails, the queue becomes unavailable. Lock contention further reduces throughput, and the architecture provides neither horizontal scalability nor strong durability guarantees.

Building blocks we will use

Building block	Used for
Databases	Store metadata for queues and users
Caches	Store frequently accessed data, such as user or queue metadata
Load balancers	Distribute incoming requests to metadata servers

Each of these has its own chapter earlier in this module — the messaging queue composes them rather than reinventing them.

Key takeaway

Five operations, with delete deliberately separate from receive. Four non-functional requirements, of which durability is the one that distinguishes a queue from a cache. And a single-server queue fails all four — the lock being the failure that worsens as you add clients.

Interview signal by level

Level	What a strong answer sounds like
L4	"Send, receive, and delete messages, and it should be scalable and available."
L5	Names the single-server limits: "one machine is a SPOF with no replication, so no durability, and the lock caps throughput."
Staff+	Explains why the lock is the interesting one: "the queue is a critical section, so adding producers and consumers adds contention rather than throughput — it degrades inversely with load, which is why a bigger machine doesn't help. And durability is non-negotiable here in a way it isn't for a cache: once we ack, ours is the only copy."

Next: the hardest requirement to satisfy — order.