Blog
Queues vs Streams - What We Learned from Chris Simon at DDD Europe
Posted on 2026-09-07 - 4 minute read
Chris Simon's talk, "It's Like 10,000 Streams When What You Need Is a Queue," tackles a question every team building event-driven architecture eventually hits: once you've done the event storming and identified your domain events, which technology should actually carry them? A queue, such as RabbitMQ or SQS? A stream, such as Kafka? Or an event store? Here's what we took away.
Queues and streams solve different problems, not the same problem differently
The core distinction is statefulness. With a queue, the broker tracks whether a message has been consumed. With a stream, that responsibility sits with the consumer, which has to track its own read position (its offset) in the log. This single difference cascades into everything else: how each system scales, how each recovers from failures, and how each handles a message that repeatedly fails to process.
Queues give you dead-letter queues and automatic retry handling for free. Streams give you a durable history of every message ever sent, but leave failure handling and read-position tracking to you.
Pick based on what you actually need, not what's trendy
The talk offers a clear, practical heuristic:
- Business process choreography, where every message matters and a missed one means a missed payment or shipment, calls for a queue.
- Streaming analytics, where individual messages are less important than the overall pattern, is what streams were built for.
- State management and historical record-keeping is the job of a dedicated event store, not a repurposed stream.
Trying to make Kafka do the job of an event store, Simon argues, is a common and costly mistake: streams are optimised to query by topic and offset, while event sourcing needs to query by entity, a fundamentally different access pattern.
Public and private events need very different treatment
One of the clearer distinctions in the talk is between private domain events, which support internal decision-making, and public domain events, which other bounded contexts subscribe to. Public events should stay thin, carrying only what's needed, since anything more increases the risk that changing that event breaks a downstream consumer. Simon's practical fix for keeping public events genuinely thin without falling into the "clickbait event" anti-pattern: put the data where it's actually needed at the point each bounded context is designed, rather than forcing consumers to call back for more information.
What participants said:
It was both fun and useful!
Spot on on everything and a great speaker. Ensure everyone in the organisation sees the talk.