← Back to Database and Storage

Four Queue Types

Four queue structures and the insertion and removal rules that define them.

Database and StorageData StructuresQueues

A queue is not one thing. The word covers several data structures that all manage ordered work, but they optimise for different insertion rules, removal rules, and latency targets. The right choice depends on whether order matters most, whether memory is fixed, whether some items must jump the line, and whether both ends of the structure need to stay active.

Simple FIFO queue

A FIFO queue is the plainest form: enqueue at the tail, dequeue at the head. If task A enters before task B, task A leaves first. This is the right mental model for work that should be processed in arrival order, such as sending email receipts after successful payments or serialising writes to a single downstream system.

The mechanics are simple, but the operational consequence is important. FIFO preserves fairness only if consumers process items at roughly similar speed. One slow item at the head can still block later work. That is why production message queues often combine FIFO semantics with visibility timeouts, dead-letter queues, or partitioning by key.

Circular queue

A circular queue, also called a ring buffer, stores items in a fixed-size array and wraps the write and read pointers back to the start when they reach the end. The queue never needs to shift elements in memory, so it gives predictable allocation behaviour and strong cache locality.

This is why ring buffers show up in low-latency systems such as trading engines, packet processing, audio pipelines, and telemetry collectors. If the producer and consumer can coordinate without locks, the structure can be extremely fast.

The tradeoff is capacity discipline. A ring buffer is usually bounded. When the producer catches up with the consumer, the system must choose between blocking, dropping old items, or rejecting new ones. That makes circular queues excellent for controlled in-memory pipelines and poor for durable backlog storage.

Priority queue

A priority queue removes the item with the highest or lowest priority rather than the oldest item. Heaps are a common implementation because they support insertion and removal in logarithmic time while keeping the top-priority element easy to access.

This is useful when urgency matters more than arrival order. An operating system scheduler may run high-priority tasks first. A hospital triage system does not treat all arrivals equally. A job runner may prioritise fraud checks ahead of lower-value background reporting.

The tradeoff is starvation. If high-priority work keeps arriving, low-priority items may never run. Real systems often add ageing, weighted fairness, or separate queues per class to stop urgent traffic from permanently crowding out everything else.

Deque

A deque, or double-ended queue, supports insertion and removal at both the head and the tail. That flexibility makes it useful when the system needs queue behaviour in some paths and stack-like behaviour in others. Work-stealing schedulers are a good example: a worker often pushes and pops from one end locally, while other workers steal from the opposite end when they run out of work.

Deques are also useful for sliding-window algorithms, LRU cache bookkeeping, and task schedulers that occasionally need to requeue urgent work at the front without rebuilding the whole structure.

The cost of that flexibility is extra policy. Once both ends are active, the caller must define what each end means. If the application has no clear rule for front versus back, a deque can quietly turn into a source of inconsistent behaviour.

Choosing between them

The shortest rule is practical. Use a FIFO queue when preserving arrival order is the contract. Use a circular queue when bounded memory and predictable low latency matter more than durability. Use a priority queue when importance must override time order. Use a deque when both ends serve a real purpose in the algorithm.

All four are common because they solve different bottlenecks. The data structure should match the scheduling rule you actually need, not the one that happens to be easiest to name.