Message Queue

A message queue is the holding bay between systems: one system drops off work, another picks it up when it can. That simple decoupling — send-and-forget on one side, process-at-capacity on the other — is how modern systems absorb spikes, survive partial failure, and keep functioning when a partner system is down.

What It Is

A message queue is middleware that receives messages (work items, events, requests) from producers and holds them reliably until consumers retrieve and process them. Guarantees vary by technology but the serious ones offer delivery assurance (a message is not lost once accepted), ordering options, and dead-letter handling (messages that repeatedly fail processing are parked for attention instead of blocking the queue). Patterns built on queues include task distribution (many workers draining one queue), event-driven architecture (systems reacting to events others publish), and load-levelling (a burst of arrivals smoothing into steady processing).

Why It Matters to You

Queues convert the executive's favourite failure mode — the cascade, where one slow system backs up everything behind it — into contained delay: arrivals keep being accepted while the backlog drains. That resilience has a visible operational signature your teams will recognise: backlogs, which are a queue functioning exactly as designed but requiring monitoring (a growing queue is capacity debt) and communication ('your order is queued' is honest system state, not an excuse). In architecture reviews, the presence of queues between systems is a marker of decoupled design; their absence between systems of different criticality is a marker of cascade risk.

When You'll Meet It

In architecture diagrams and incident reviews. When integration failures cascade, the postmortem usually recommends the queue that the design meeting declined.