SOFTWARE / SYSTEMS / AIEngineering news. Technical depth.
Comparisons / 2 MIN READ

Choose Queues or Streams by How You Need to Recover

Compare disposable jobs and retained facts through ownership, replay, ordering, fan-out, retention, and consumer recovery.

Choose from the recovery contract

Choose a queue when one worker should own disposable work and completion removes it from active backlog. Choose a stream when the record is a retained fact that several consumers may replay independently. Recovery behavior is the decisive distinction. Apache Kafka documentation supplies the primary specification or operating model for this decision.

Separate invoice facts from rendering jobs

An invoice.created fact belongs in a stream so accounting and analytics keep separate positions and can rebuild. A render invoice PDF command belongs in a queue so one worker claims, retries, and completes it. Combining both models often expresses intent best. Amazon SQS documentation provides the complementary protocol or operational detail.

Start with the recovery question

Use a queue when work should be claimed, completed, retried, and eventually removed. Use a retained stream when independent consumers need their own positions, new projections must replay history, or audit requires an ordered log within a partition. Both systems can deliver duplicates; consumers still need idempotency.

A thumbnail job belongs naturally in a queue: one worker should produce each result, and a poison job can move to a dead-letter path. An order-event history fits a stream when billing, search, and analytics consume at different rates and a rebuilt index must replay months of events.

Specify failure semantics before choosing a product

Document ordering scope, retention, acknowledgement or offset ownership, retry delay, poison-record handling, backlog age, replay duration, and deletion obligations. A stream retained for seven days cannot rebuild a year-old projection. A queue that deletes on acknowledgement cannot provide a new consumer with history.

Test worker death after side effect but before acknowledgement, consumer restart from an old position, duplicate delivery, a malformed record, and retention exhaustion. Estimate the time and capacity required for full replay. Pick the architecture whose recovery procedure matches the business need, then validate it with one forced restart and one replay rather than comparing feature tables.

SOURCES & REVIEW

Sources are linked throughout this guide. Product capabilities can change; consult the linked documentation for your deployment.

Read our editorial approach ↗