In many architectures, RabbitMQ is used as a messaging layer, but event sourcing or replay capabilities are offloaded to a separate event store (e.g. EventStoreDB, MongoDB, PostgreSQL, Microsoft SQL Server). It would be advantageous if RabbitMQ itself could act as the event store so that producers/consumers can leverage one unified system with replay, retention, partitioning, etc.
Describe the solution you’d like
I propose a feature where RabbitMQ Streams can serve as a first-class event store.
The idea is that instead of having RabbitMQ just as a message broker and then pushing events into an external event store, the stream layer of RabbitMQ becomes the event store itself.
Options:
- One RabbitMQ Stream per aggregate instance (e.g.,
Booking-{bookingId})
- One RabbitMQ Superstream per aggregate type, partitioned by aggregate instance
- Superstream:
Booking
- Partition key =
bookingId
Describe alternatives you’ve considered
Keep the current pattern: use RabbitMQ for messaging, and integrate with a separate event store (e.g. Microsoft SQL Server).
Additional context
RabbitMQ Streams already supports many of the low-level features needed: non-destructive reads, replay, offsets, partitioned super-streams, etc.
The “Streams and Superstreams” documentation: https://www.rabbitmq.com/docs/streams
In many architectures, RabbitMQ is used as a messaging layer, but event sourcing or replay capabilities are offloaded to a separate event store (e.g. EventStoreDB, MongoDB, PostgreSQL, Microsoft SQL Server). It would be advantageous if RabbitMQ itself could act as the event store so that producers/consumers can leverage one unified system with replay, retention, partitioning, etc.
Describe the solution you’d like
I propose a feature where RabbitMQ Streams can serve as a first-class event store.
The idea is that instead of having RabbitMQ just as a message broker and then pushing events into an external event store, the stream layer of RabbitMQ becomes the event store itself.
Options:
Booking-{bookingId})BookingbookingIdDescribe alternatives you’ve considered
Keep the current pattern: use RabbitMQ for messaging, and integrate with a separate event store (e.g. Microsoft SQL Server).
Additional context
RabbitMQ Streams already supports many of the low-level features needed: non-destructive reads, replay, offsets, partitioned super-streams, etc.
The “Streams and Superstreams” documentation: https://www.rabbitmq.com/docs/streams