RabbitMQ Streams as an event store #432

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:

1. One RabbitMQ Stream per aggregate instance (e.g., Booking-{bookingId})
2. 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