Event-driven architecture patterns in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Event-driven architecture patterns

Event Occurs

↓

Event Published

↓

Event Bus / Queue

↓

Event Listeners / Handlers

↓

Process Event

↓

Update State / Trigger Actions

↓

Emit New Events (optional)

↩Back to Event Bus

Events happen and are sent to a central bus. Listeners pick them up, process, update state, and may emit new events.

Execution Sample

Blockchain / Solidity

eventBus.publish('Transfer', {from: 'A', to: 'B', amount: 100});

listener.on('Transfer', (event) => {
  updateBalance(event.from, -event.amount);
  updateBalance(event.to, event.amount);
});

A transfer event is published; listener updates balances accordingly.

Execution Table

Step	Action	Event	Listener Triggered	State Change	New Event Emitted
1	Publish event	Transfer {from: A, to: B, amount: 100}	No	No	No
2	Event bus queues event	Transfer {from: A, to: B, amount: 100}	No	No	No
3	Listener detects event	Transfer {from: A, to: B, amount: 100}	Yes	No	No
4	Listener processes event	Transfer {from: A, to: B, amount: 100}	Yes	Balances updated: A -= 100, B += 100	No
5	Event processing complete	Transfer {from: A, to: B, amount: 100}	No	Balances updated	No

💡 No more events in queue; processing ends.

Variable Tracker

Variable	Start	After Step 4	Final
eventQueue	[]	[Transfer event]	[]
balances	{A: 1000, B: 500}	{A: 900, B: 600}	{A: 900, B: 600}

Key Moments - 2 Insights

Why does the listener only update balances after the event is published?

Because the event must first be published and queued (see execution_table step 2) before listeners detect and process it (step 3 and 4).

Can a listener emit a new event after processing?

Yes, listeners can emit new events to the event bus to trigger further processing, but in this example no new events are emitted (see execution_table column 'New Event Emitted').

Visual Quiz - 3 Questions

Look at the execution table, at which step does the listener start processing the event?

A Step 4

B Step 3

C Step 2

D Step 5

💡 Hint

Check the 'Listener Triggered' and 'State Change' columns in execution_table rows.

According to the variable tracker, what is the balance of account B after processing?

A 500

B 400

C 600

D 1000

💡 Hint

Look at the 'balances' row in variable_tracker after Step 4.

If the listener emitted a new event after processing, which column in the execution table would show this?

A Action

B New Event Emitted

C Event

D State Change

💡 Hint

Refer to the 'New Event Emitted' column in the execution_table.

Concept Snapshot

Event-driven architecture means code reacts to events.
Events are published to a bus or queue.
Listeners wait and process events asynchronously.
Processing can update state or trigger new events.
This pattern helps decouple components and scale systems.

Full Transcript

In event-driven architecture, events are the main triggers for actions. When an event occurs, it is published to an event bus or queue. Listeners subscribe to these events and process them when they detect them. For example, a 'Transfer' event with details about sender, receiver, and amount is published. The listener updates account balances accordingly. This process is asynchronous and allows different parts of the system to work independently but stay coordinated through events. Listeners can also emit new events to continue workflows. The execution table shows each step from publishing to processing and state updates. The variable tracker shows how the event queue and balances change over time. Understanding when listeners act and how state changes helps grasp this pattern. Event-driven design is common in blockchain for handling transactions, state changes, and notifications efficiently.