Skip to content

RabbitMQ Streams as an event store #432

@nealmummau

Description

@nealmummau

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions