Skip to main content
Architecture & Engineering

Message Queue

A message queue holds tasks that one part of a system produces and another consumes later, decoupling the two so the producer does not wait for the work to finish. It absorbs traffic spikes, survives consumer restarts, and lets slow work happen outside the request that triggered it.

The classic use is removing slow operations from a user-facing path. Sending an email, generating a report or processing an upload does not need to block an HTTP response — the request enqueues the work and returns immediately, while a worker handles it independently.

Queues also provide backpressure. When consumers cannot keep up, the queue grows rather than the system failing, giving time to scale workers up. The design requirement this introduces is idempotency: a message may be delivered more than once after a failure, so processing it twice must be harmless. Systems that assume exactly-once delivery break in production.

FAQ

Message Queue
FAQ.

Common questions about message queue.

Ask Us Anything

It means processing the same message twice produces the same result as processing it once. Because most queues guarantee at-least-once delivery, duplicates are normal after a crash or timeout. Achieving idempotency usually means recording a processed-message identifier and skipping repeats, or designing operations that are naturally safe to repeat.

Related terms

Event-Driven Architecture

Event-driven architecture is a design where components publish events describing something that happened, and other components react to them, without the publisher knowing who is listening.

Microservices

Microservices are an architecture where an application is split into small independent services, each owning one business capability and its own data, communicating over a network.

Webhooks

Webhooks are HTTP callbacks that one system sends to another when an event occurs, so the receiver learns about it immediately instead of polling for changes.

Browse the full glossary →