> ## Documentation Index
> Fetch the complete documentation index at: https://agentconcepts.io/llms.txt
> Use this file to discover all available pages before exploring further.
# queue
> FIFO buffer for asynchronous work; decouples producer from consumer in time, rate, and identity. The queue absorbs producer bursts and feeds consumers at their own pace.
business computer-science mathematics medicine-and-health transportation
# Queue
## Description
A queue is a FIFO buffer that decouples producer from consumer in time, rate, and identity. The producer doesn't have to wait for the consumer to finish processing; the consumer doesn't have to keep up with the producer's instantaneous rate. The queue absorbs the temporal mismatch and preserves order. The structural payoff is asynchrony with bounded memory (if the queue is bounded) and load-leveling (consumers see a smoothed rate, not the producer's bursts).
The diagnostic shape: any producer-consumer pair where their rates differ in the short term, where the work is independent enough to be batched-and-handed-off, and where order preservation (or partition-order preservation, in a sharded queue) matters. Queues are the load-bearing primitive under message brokers, async task systems, OS process scheduling, postal services, and most multi-stage industrial processes.
Queue is structurally the *buffer* half of the bottleneck-buffer pair. Bottleneck names the rate-limiting step; buffer names the reservoir that smooths the upstream. Queue is the canonical implementation of the buffer. The vocabulary differs by community — message broker, work queue, task queue, mailbox, inbox — but the structural primitive is one.
## Triggers
**User-initiated:** User describes producer-consumer rate mismatch, wants to add asynchrony, or proposes decoupling components. Vocabulary cues: "queue," "FIFO," "message broker," "work queue," "task queue," "Kafka," "SQS," "producer," "consumer."
**Agent-initiated:** Agent notices a synchronous request-response pattern where the response isn't immediately needed (the caller is waiting unnecessarily). Candidate inference: "this could be a queue — what's the work item, who's the consumer, and what's the at-least-once-vs-exactly-once requirement?"
**Situation-shape signals:** Producer-consumer rate mismatch; asynchronous processing acceptable; need to scale producer and consumer independently; need durability of in-flight work.
## Exclusions
* **Synchronous response required** — if the consumer's output is needed in the caller's request scope, the queue's asynchrony is incompatible.
* **No producer-consumer rate mismatch** — if the producer always waits for the consumer anyway, the queue is overhead without benefit.
* **Strict ordering across producers required globally** — FIFO is per-queue (or per-partition in sharded queues); across-partition global ordering requires consensus, not just queueing.
* **Memory-cost is dominant and load is well-controlled** — for bounded systems with smooth rates, direct synchronous calls may be cheaper than queue infrastructure.
## Structure
\= **a producer + a container (the queue itself, FIFO-ordered) + a consumer + delivery semantics**. Bounded queues are critical for backpressure (the fullness IS the signal); unbounded queues are a footgun (they can silently fill memory until the system OOMs).
## Relationships
* [bottleneck-buffer](/concepts/bottleneck-buffer) — queue is the buffer; bottleneck is the consumer's rate limit.
* [backpressure](/concepts/backpressure) — bounded queues signal backpressure via fullness.
* [flow](/concepts/flow) — queues are flow with explicit ordering and buffering.
* [seam](/concepts/seam) — queues are seams between async components.
* [load-balancing](/concepts/load-balancing) — multiple consumers competing for a queue is the simplest load-balance.
* [write-ahead-log](/concepts/write-ahead-log) — durable queues (Kafka) are structurally WALs promoted to architectural primitives.
## Examples
direct human-system instance; "now serving #47" is the dequeue signal.
patients queue; doctors dequeue; priority-queue with severity-based reordering.
Apache Kafka documentation and the original LinkedIn paper (Kreps et al., 2011) — the canonical durable-distributed-queue.
processor-internal queue absorbing dependency-stall mismatches between fetch and execute.
incoming tickets queue; agents dequeue; SLA timers measure queue dwell.
emails queue at arrival; reader dequeues; the queue can grow unbounded.
Erlang's 1909 paper is the founding document of queueing theory, written to solve a concrete engineering problem at the Copenhagen Telephone Company: how many circuits does an exchange need so that callers rarely find every line busy? Erlang's contribution was to model the *arrivals* — he showed that incoming calls form a Poisson process (independent events at a constant average rate), which made the random load mathematically tractable for the first time. From that model he could relate traffic intensity to the probability that an arriving call has to wait, giving telephone engineers a principled way to size capacity instead of guessing. (The explicit blocking/delay formulas now called Erlang B and Erlang C came in his 1917 follow-up.)
**Inference**: Erlang gives the queue primitive its origin and its core insight: a queue forms wherever a stochastic arrival stream meets a finite-capacity server. The arriving items are the calls; the server is the bank of circuits; the waiting line is what materializes when arrivals temporarily exceed capacity. The transferable structural lesson is that queue behavior is governed not by averages but by the *randomness* of arrivals relative to service — a system provisioned for the average load still produces long waits because Poisson arrivals cluster. That is why every later queue, from CPU schedulers to checkout lines to packet routers, inherits Erlang's framing: model the arrival process, not just the mean rate.
canonical distributed-systems engineering instances.
Kleinrock's *Queueing Systems, Volume 1: Theory* (1975) is the canonical graduate-level consolidation of queueing theory, the text that carried it from an operations-research subfield into the analytic backbone of computer-network design. It gives the exhaustive treatment of the M/M/1 queue (single server, Poisson arrivals, exponential service) and develops Little's Law (L = λW) — the universal conservation relation between average number-in-system, arrival rate, and waiting time that holds regardless of the queue's internal discipline. Kleinrock's own ARPANET work built directly on this foundation: the "independence assumption" that let a packet-switched network be analyzed as a network of independent M/M/1 queues at each node.
**Inference**: Kleinrock supplies the queue primitive's general theory — the formal tools that make any queue predictable. The arriving items, the server, and the waiting line are the same roles Erlang named, but Kleinrock gives the invariants: Little's Law in particular is the structural gift, because it relates the three quantities a queue-operator actually cares about without needing to know the arrival distribution's details. The transferable lesson is that queues across wildly different domains obey the *same* conservation laws — so the intuition "to cut waiting time, either reduce arrivals or add service capacity" is not a heuristic but a theorem, and a queue that grows without bound is the signature of arrival rate exceeding service rate, in a telephone exchange or a message broker alike.
Kleppmann's *Designing Data-Intensive Applications* treats message queues and log-structured streams as foundational building blocks for distributed systems: a queue decouples a producer from a consumer in time, smoothing throughput mismatches and providing a buffer in which messages can wait without blocking either side. Chapter 11 surveys modern message-queue and log-based stream-processing systems — Kafka, AMQP brokers, JMS, cloud queues — under a unifying frame that distinguishes the durability, ordering, and delivery-guarantee dimensions production deployments actually trade off. Operating-systems texts (Tanenbaum) cover the same primitive at process-scheduling and I/O level — runnable processes wait in queues to be granted CPU; I/O requests wait in queues to be dispatched to devices.
**Inference**: The queue shape — FIFO buffer for asynchronous work, decoupling producer from consumer — recurs across substrates separated by decades and scale. Postal sorting, deli lines, OS run queues, message brokers (Kafka, RabbitMQ, SQS), and customer-service ticket systems all instantiate it. The decoupling-in-time property is what licenses the cross-domain transfer; it's also what separates the queue from immediate hand-off patterns where the producer waits.
runnable processes in a FIFO (or priority) queue; scheduler dequeues.
letters queue at sort points; sorters dequeue; multi-stage queueing across processing stations.
print jobs queued; printer is the slow consumer; the queue absorbs the rate mismatch.
century-old mathematical lineage — queueing theory is one of the oldest applied-mathematics disciplines and provides the formal framework (M/M/1, M/M/c, Little's law) for reasoning about queue behavior under load
Tanenbaum's *Modern Operating Systems* is the standard textbook treatment of the queue as the central data structure of CPU scheduling. Processes occupy three states — running, ready, and blocked — and the *ready queue* is the line of runnable processes waiting for the CPU: the scheduler's job is to pick which ready process runs next. The cleanest queue instance is round-robin scheduling, a FIFO discipline in which the scheduler takes the process at the head, runs it for one quantum, and on expiry preempts it to the *back* of the queue. Priority scheduling generalizes this to multiple queues — one per priority level — with the scheduler always drawing from the highest-priority non-empty queue.
**Inference**: The OS ready queue is the queue primitive operating at machine timescales. The arriving items are runnable processes; the server is the CPU; the waiting line is the ready queue; the *discipline* (FIFO round-robin vs. priority) is the policy choosing who waits and who runs. The transferable lesson Tanenbaum makes concrete is that the queue's *service discipline* is a design lever with explicit trade-offs: too short a quantum and context-switching overhead dominates; too long and interactive response suffers; pure FIFO is fair but starves urgent work, while priority queues serve urgency but can starve the low-priority tail. The choice of discipline — not just the existence of the queue — determines the system's behavior under load.