Event sourcing with RabbitMQ - Step-by-Step Execution

Process Flow - Event sourcing with RabbitMQ

Event Occurs

↓

Publish Event to RabbitMQ Exchange

↓

Exchange Routes Event to Queue(s)

↓

Consumer Reads Event from Queue

↓

Consumer Processes Event and Updates State

↓

State is Rebuilt from Event Stream if Needed

Events are sent to RabbitMQ, routed to queues, consumed to update state, enabling state reconstruction from event history.

Execution Sample

RabbitMQ

rabbitmqadmin publish exchange=events_exchange routing_key=order.created payload='{"orderId":123, "status":"created"}'

# Consumer reads from queue
rabbitmqadmin get queue=order_events_queue count=1

# Consumer processes event and updates state

This sequence shows publishing an event to RabbitMQ, consuming it from a queue, and processing it to update application state.

Process Table

Step	Action	RabbitMQ Component	Event Data	Result
1	Publish event	Exchange: events_exchange	{"orderId":123, "status":"created"}	Event sent to exchange
2	Route event	Exchange routes to queue	Same event	Event placed in queue: order_events_queue
3	Consume event	Queue: order_events_queue	Same event	Consumer reads event from queue
4	Process event	Consumer application	Same event	State updated with orderId 123 status created
5	Rebuild state	Consumer application	All past events	State rebuilt from event stream if needed

💡 All events processed and state updated; event sourcing flow complete

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
Event Data	{}	{"orderId":123, "status":"created"}	{"orderId":123, "status":"created"}	{"orderId":123, "status":"created"}	{"orderId":123, "status":"created"}	{"orderId":123, "status":"created"}
Queue State	empty	empty	contains 1 event	empty after consume	empty	empty
Application State	empty	empty	empty	updated with orderId 123 status created	updated	updated

Key Moments - 3 Insights

Why does the event stay the same through all steps?

The event data is immutable; it is published once and passed unchanged through exchange, queue, and consumer to ensure consistent state updates, as shown in execution_table rows 1 to 4.

What happens to the queue after the consumer reads the event?

After the consumer reads the event, the event is removed from the queue, making the queue empty again, as seen in variable_tracker 'Queue State' after Step 3.

How does the application rebuild state from events?

The application replays all past events from the event stream to reconstruct the current state, ensuring no data loss, as described in execution_table Step 5.

Visual Quiz - 3 Questions

Look at the execution table, what RabbitMQ component routes the event to the queue?

A Queue

B Consumer

C Exchange

D Publisher

💡 Hint

See Step 2 in the execution_table where routing happens via the Exchange.

At which step does the consumer update the application state?

A Step 4

B Step 3

C Step 2

D Step 5

💡 Hint

Check Step 4 in execution_table where processing and state update occur.

If the queue is empty after consuming, what is the queue state after Step 3 in variable_tracker?

A contains 1 event

B empty

C unknown

D full

💡 Hint

Refer to 'Queue State' row in variable_tracker after Step 3.

Concept Snapshot

Event sourcing with RabbitMQ:
- Events are published to an exchange.
- Exchange routes events to queues.
- Consumers read events from queues.
- Consumers update application state from events.
- State can be rebuilt by replaying all events.

Full Transcript

Event sourcing with RabbitMQ means sending events to a RabbitMQ exchange. The exchange routes these events to queues. Consumers read events from these queues and update the application state accordingly. This allows the application to rebuild its state by replaying all past events. The flow starts with publishing an event, routing it, consuming it, processing it, and optionally rebuilding state from the event stream.

Practice

1. What is the main purpose of event sourcing in RabbitMQ?

easy

A. To record all changes as a sequence of events

B. To delete old messages automatically

C. To speed up message delivery by skipping queues

D. To encrypt messages before sending

Solution

1. Step 1: Understand event sourcing concept

   Event sourcing means storing every change as an event, not just the current state.

2. Step 2: Connect event sourcing to RabbitMQ

   RabbitMQ can store and forward these events reliably using exchanges and queues.

3. Final Answer:

   To record all changes as a sequence of events -> Option A

4. Quick Check:

   Event sourcing = record all changes as events [OK]

Hint: Event sourcing means saving every change as an event [OK]

Common Mistakes:

• Thinking event sourcing deletes old data
• Confusing event sourcing with encryption
• Assuming event sourcing skips queues

2. Which RabbitMQ component is responsible for routing events to queues based on routing keys?

easy

A. Queue

B. Binding

C. Channel

D. Exchange

Solution

1. Step 1: Identify RabbitMQ components

   Exchanges receive messages and decide where to send them using routing keys.

2. Step 2: Role of routing keys and bindings

   Bindings connect exchanges to queues, but routing decisions happen inside exchanges.

3. Final Answer:

   Exchange -> Option D

4. Quick Check:

   Routing keys route messages via exchanges [OK]

Hint: Exchanges route messages using routing keys [OK]

Common Mistakes:

• Confusing bindings as routing decision makers
• Thinking queues route messages
• Mixing channels with routing

3. Given this RabbitMQ setup:

channel.exchange_declare(exchange='events', exchange_type='direct')
channel.queue_declare(queue='order_events')
channel.queue_bind(queue='order_events', exchange='events', routing_key='order.created')
channel.basic_publish(exchange='events', routing_key='order.created', body='Order123')

What happens when the message is published?

medium

A. Message causes an error due to missing routing key

B. Message is discarded because no queue matches

C. Message is sent to 'order_events' queue

D. Message is sent to all queues bound to 'events' exchange

Solution

1. Step 1: Analyze exchange and queue binding

   The 'events' exchange is direct type, routing key 'order.created' binds to 'order_events' queue.

2. Step 2: Check message publish routing

   Message with routing key 'order.created' matches binding, so it goes to 'order_events' queue.

3. Final Answer:

   Message is sent to 'order_events' queue -> Option C

4. Quick Check:

   Direct exchange routes by exact routing key [OK]

Hint: Direct exchange sends message only to matching routing key queue [OK]

Common Mistakes:

• Assuming message goes to all queues
• Thinking message is discarded without error
• Forgetting routing key is required

4. You wrote this code to bind a queue but it doesn't receive messages:

channel.queue_bind(queue='events_queue', exchange='events_exchange', routing_key='user.updated')

What is the most likely reason messages are not received?

medium

A. The queue was not declared before binding

B. The routing key used in publishing does not match 'user.updated'

C. The exchange type does not support routing keys

D. The channel was closed before binding

Solution

1. Step 1: Verify routing key matching

   Messages only reach queues if routing keys match bindings exactly.

2. Step 2: Check publishing routing key

   If published messages use a different routing key, queue won't get them despite binding.

3. Final Answer:

   The routing key used in publishing does not match 'user.updated' -> Option B

4. Quick Check:

   Routing keys must match for delivery [OK]

Hint: Routing keys must match exactly to deliver messages [OK]

Common Mistakes:

• Assuming exchange type blocks routing keys
• Forgetting to declare queue before binding
• Not checking if channel is open

5. You want to implement event sourcing with RabbitMQ to track user actions. Which setup best ensures all user events are stored and can be replayed later?

hard

A. Use a topic exchange with queues bound by event patterns, and enable message persistence and acknowledgments

B. Use a fanout exchange to broadcast events to multiple queues, each storing events for different services

C. Use a direct exchange with one queue per event type, but do not persist messages after consumption

D. Use a headers exchange without bindings, relying on message headers only

Solution

1. Step 1: Understand event sourcing needs

   Event sourcing requires storing all events reliably and replaying them later.

2. Step 2: Evaluate exchange types and persistence

   Topic exchange allows flexible routing by event patterns; persistence and acknowledgments ensure events are saved and not lost.

3. Step 3: Compare options

   Fanout broadcasts but may not filter; direct without persistence loses events; headers without bindings is unreliable.

4. Final Answer:

   Use a topic exchange with queues bound by event patterns, and enable message persistence and acknowledgments -> Option A

5. Quick Check:

   Topic exchange + persistence = reliable event sourcing [OK]

Hint: Use topic exchange with persistence for flexible, reliable event storage [OK]

Common Mistakes:

• Ignoring message persistence
• Using fanout without filtering
• Relying on headers exchange without bindings