Event sourcing with RabbitMQ - Commands & Configuration

Introduction

Event sourcing is a way to record every change in your system as a sequence of events. RabbitMQ helps by sending and storing these events as messages, so you can track what happened and rebuild system state anytime.

When you want to keep a full history of changes to your data for auditing or debugging.

When you need to replay past events to restore system state after a failure.

When multiple parts of your system need to react to the same events independently.

When you want to decouple services so they communicate by sending events instead of direct calls.

When you want to scale event processing by distributing messages across multiple consumers.

Config File - event_sourcing_setup.sh

event_sourcing_setup.sh

#!/bin/bash

# Create a durable exchange for event sourcing
rabbitmqadmin declare exchange name=event_exchange type=fanout durable=true

# Create a durable queue to store events
rabbitmqadmin declare queue name=event_store durable=true

# Bind the queue to the exchange to receive all events
rabbitmqadmin declare binding source=event_exchange destination=event_store

This script sets up RabbitMQ for event sourcing:

• exchange: A durable fanout exchange named event_exchange that broadcasts events to all bound queues.
• queue: A durable queue named event_store that stores all events reliably.
• binding: Connects the exchange to the queue so all events sent to the exchange go into the queue.

Commands

Create a durable fanout exchange named 'event_exchange' to broadcast events to all queues bound to it.

Terminal

rabbitmqadmin declare exchange name=event_exchange type=fanout durable=true

Expected Output

{"name":"event_exchange","type":"fanout","durable":true,"auto_delete":false,"internal":false,"arguments":{}}

→

name=event_exchange - Sets the exchange name

→

type=fanout - Broadcasts messages to all bound queues

→

durable=true - Keeps exchange after RabbitMQ restarts

Create a durable queue named 'event_store' to store all event messages reliably.

Terminal

rabbitmqadmin declare queue name=event_store durable=true

Expected Output

{"name":"event_store","durable":true,"auto_delete":false,"arguments":{}}

→

name=event_store - Sets the queue name

→

durable=true - Keeps queue after RabbitMQ restarts

Bind the 'event_store' queue to the 'event_exchange' so it receives all events sent to the exchange.

Terminal

rabbitmqadmin declare binding source=event_exchange destination=event_store

Expected Output

{"source":"event_exchange","destination":"event_store","destination_type":"queue","routing_key":""}

→

source=event_exchange - The exchange sending messages

→

destination=event_store - The queue receiving messages

Send an event message about a new user creation to the 'event_exchange'. This message will be stored in the 'event_store' queue.

Terminal

rabbitmqadmin publish exchange=event_exchange routing_key= payload='{"event":"user_created","data":{"id":1,"name":"Alice"}}'

Expected Output

{"routed":true}

→

exchange=event_exchange - Send message to this exchange

→

routing_key= - Empty for fanout exchange

→

payload= - The event data in JSON format

Retrieve one event message from the 'event_store' queue to verify it was stored correctly.

Terminal

rabbitmqadmin get queue=event_store requeue=false count=1

Expected Output

  {

    "payload": "{\"event\":\"user_created\",\"data\":{\"id\":1,\"name\":\"Alice\"}}",

    "payload_bytes": 56,

    "redelivered": false,

    "exchange": "event_exchange",

    "routing_key": "",

    "message_count": 0

  }

→

queue=event_store - The queue to get messages from

→

requeue=false - Remove message from queue after getting

→

count=1 - Get one message

Key Concept

If you remember nothing else from this pattern, remember: RabbitMQ stores every event as a message so you can replay or audit system changes anytime.

Common Mistakes

Creating a non-durable exchange or queue

Events will be lost if RabbitMQ restarts, breaking event sourcing reliability.

Always set durable=true for exchanges and queues to keep events safe across restarts.

Using a direct exchange instead of fanout for event broadcasting

Events will only go to queues matching the routing key, missing other consumers.

Use a fanout exchange to broadcast events to all interested queues.

Not binding the queue to the exchange

Events sent to the exchange won't reach the queue, so no events are stored.

Always bind your event store queue to the event exchange.

Summary

Create a durable fanout exchange to broadcast all events.

Create a durable queue to store all event messages reliably.

Bind the queue to the exchange so it receives every event.

Publish event messages to the exchange to record system changes.

Retrieve messages from the queue to replay or audit events.