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.