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.

Practice

1. What is the main purpose of event-driven architecture in blockchain applications?

easy

A. To allow smart contracts to emit events that trigger automatic responses

B. To store large amounts of data on the blockchain

C. To speed up the mining process

D. To encrypt transactions for security

Solution

1. Step 1: Understand event-driven architecture basics

   Event-driven architecture means systems react automatically to events or actions.

2. Step 2: Apply this to blockchain context

   In blockchain, smart contracts emit events that apps listen to and respond automatically.

3. Final Answer:

   To allow smart contracts to emit events that trigger automatic responses -> Option A

4. Quick Check:

   Event-driven architecture = automatic reactions to events [OK]

Hint: Event-driven means automatic reaction to smart contract events [OK]

Common Mistakes:

• Confusing event-driven with data storage
• Thinking it speeds up mining
• Mixing encryption with event handling

2. Which of the following is the correct syntax to listen for an event named Transfer in a blockchain app using JavaScript?

easy

A. contract.listen('Transfer', function(from, to, amount) {});

B. contract.emit('Transfer', (from, to, amount) => {});

C. contract.on('Transfer', (from, to, amount) => { /* handle event */ });

D. contract.catch('Transfer', (from, to, amount) => {});

Solution

1. Step 1: Identify correct event listening method

   In JavaScript blockchain libraries, on is used to listen for events.

2. Step 2: Check syntax for event callback

   The callback receives event parameters like from, to, and amount.

3. Final Answer:

   contract.on('Transfer', (from, to, amount) => { /* handle event */ }); -> Option C

4. Quick Check:

   Use on to listen for events [OK]

Hint: Use .on() method to listen for blockchain events in JS [OK]

Common Mistakes:

• Using .emit() instead of .on() to listen
• Using .listen() which is invalid
• Using .catch() which is for errors

3. Given this Solidity event and JavaScript listener:

event Deposit(address indexed user, uint amount);
contract.on('Deposit', (user, amount) => { console.log(amount.toString()); });

What will be printed if the event is emitted with amount = 500?

medium

A. 0x1f4

B. 500

C. undefined

D. Error: amount.toString is not a function

Solution

1. Step 1: Understand event parameters

   The event emits amount as a number (uint) which is received in JS as a BigNumber or number.

2. Step 2: Check the listener code

   The listener calls amount.toString() which converts the number 500 to string "500".

3. Final Answer:

   500 -> Option B

4. Quick Check:

   amount.toString() converts number 500 to string '500' [OK]

Hint: toString() converts number to string for console output [OK]

Common Mistakes:

• Thinking amount prints as hex
• Assuming amount is undefined
• Confusing toString() usage

4. Identify the error in this JavaScript event listener code for a blockchain contract:

contract.on('Approval', (owner, spender, value) => {
  console.log('Approved:', owner, spender, value.toString);
});

medium

A. contract.on is not a function

B. Wrong event name 'Approval'

C. Callback parameters are incorrect

D. Missing parentheses after value.toString

Solution

1. Step 1: Check usage of toString method

   The code uses value.toString without parentheses, so it logs the function reference, not the string.

2. Step 2: Correct usage requires parentheses

   It should be value.toString() to convert the value to a string for logging.

3. Final Answer:

   Missing parentheses after value.toString -> Option D

4. Quick Check:

   toString() needs () to call method [OK]

Hint: Call toString() with parentheses to convert value [OK]

Common Mistakes:

• Forgetting () after toString
• Assuming event name is wrong
• Misunderstanding callback parameters

5. You want to build a blockchain app that updates user balances automatically when a BalanceUpdated event is emitted by a smart contract. Which event-driven pattern best fits this use case?

hard

A. Event Listener pattern to react and update balances on event emission

B. Command Query Responsibility Segregation (CQRS) to separate reads and writes

C. Event Sourcing to store all balance changes as events

D. Batch Processing to update balances periodically

Solution

1. Step 1: Understand the requirement

   The app must update balances automatically when an event occurs.

2. Step 2: Match the pattern to the need

   The Event Listener pattern listens for events and triggers immediate updates, fitting this use case perfectly.

3. Final Answer:

   Event Listener pattern to react and update balances on event emission -> Option A

4. Quick Check:

   Use Event Listener for automatic reaction to events [OK]

Hint: Use Event Listener to react instantly to blockchain events [OK]

Common Mistakes:

• Confusing Event Sourcing with immediate updates
• Choosing CQRS which separates reads/writes but not event reaction
• Using Batch Processing which delays updates