Event-driven architecture pattern in Spring Boot - Step-by-Step Execution

Concept Flow - Event-driven architecture pattern

Event Occurs

↓

Event Published

↓

Event Broker/Bus

↓

Event Listeners/Subscribers

↓

Event Handlers Execute

↓

System Reacts to Event

This flow shows how an event is created, published to a broker, and then handled by listeners that react to it.

Execution Sample

Spring Boot

public class OrderCreatedEvent {
  private final String orderId;
  public OrderCreatedEvent(String orderId) { this.orderId = orderId; }
  public String getOrderId() { return orderId; }
}

@Component
public class OrderEventListener {
  @EventListener
  public void handleOrderCreated(OrderCreatedEvent event) {
    System.out.println("Order created: " + event.getOrderId());
  }
}

This code defines an event and a listener that reacts when the event is published.

Execution Table

Step	Action	Event State	Listeners Invoked	Output
1	OrderCreatedEvent instance created with orderId='1234'	OrderCreatedEvent(orderId='1234')	None yet	No output
2	Event published to Spring event bus	Event queued for delivery	None yet	No output
3	Spring event bus dispatches event	Event dispatched	OrderEventListener.handleOrderCreated	Prints: 'Order created: 1234'
4	Listener processes event	Event handled	OrderEventListener.handleOrderCreated	Listener logic executed
5	Event processing complete	No pending events	None	No further output

💡 All listeners have processed the event; event handling cycle ends.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
orderId	null	'1234'	'1234'	'1234'	'1234'
event	null	OrderCreatedEvent(orderId='1234')	OrderCreatedEvent(orderId='1234')	OrderCreatedEvent(orderId='1234')	null (handled)
listenersInvoked	[]	[]	[]	[OrderEventListener.handleOrderCreated]	[OrderEventListener.handleOrderCreated]

Key Moments - 3 Insights

Why doesn't the event listener run immediately when the event object is created?

Creating the event object (Step 1) just prepares data. The listener runs only after the event is published to the event bus (Step 2) and dispatched (Step 3), as shown in the execution_table.

Can multiple listeners handle the same event?

Yes. The event bus dispatches the event to all registered listeners. The execution_table shows one listener, but others would be invoked similarly.

What happens if no listener is registered for an event?

The event is published and dispatched but no listeners run. The event handling cycle ends with no output, as no handlers process it.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the event listener first invoked?

A Step 1

B Step 3

C Step 2

D Step 5

💡 Hint

Check the 'Listeners Invoked' column in the execution_table.

According to variable_tracker, what is the value of 'event' after Step 3?

A OrderCreatedEvent(orderId='1234')

B null

C Event handled

D Event queued for delivery

💡 Hint

Look at the 'event' row under 'After Step 3' in variable_tracker.

If we add another listener, how would the 'Listeners Invoked' column change at Step 3?

A It would remain empty

B It would list only the first listener

C It would list both listeners

D It would show an error

💡 Hint

Refer to the explanation in key_moments about multiple listeners.

Concept Snapshot

Event-driven architecture uses events to trigger actions.
Events are objects representing something that happened.
Publish events to an event bus or broker.
Listeners subscribe to events and react when events occur.
Spring Boot uses @EventListener to handle events synchronously by default.
This decouples components and improves scalability.

Full Transcript

In event-driven architecture, components communicate by sending and receiving events. When something important happens, an event object is created. This event is then published to an event bus, which delivers it to all listeners registered for that event type. Listeners react by running their event handling code. In Spring Boot, you define event classes and listener methods annotated with @EventListener. The flow starts with event creation, then publishing, dispatching, listener invocation, and finally handling completion. Variables like the event object and listeners invoked change state as the event moves through the system. This pattern helps keep parts of the system loosely connected and responsive to changes.

Practice

1. What is the main purpose of the event-driven architecture pattern in Spring Boot?

easy

A. To store data in a relational database

B. To allow different parts of the application to communicate by sending and receiving events

C. To create user interfaces with HTML and CSS

D. To handle HTTP requests directly without any middleware

Solution

1. Step 1: Understand event-driven architecture basics

   This pattern lets components send and listen to events to communicate asynchronously.

2. Step 2: Identify Spring Boot usage

   Spring Boot uses Java classes and annotations to implement this pattern for flexible communication.

3. Final Answer:

   To allow different parts of the application to communicate by sending and receiving events -> Option B

4. Quick Check:

   Event-driven communication = To allow different parts of the application to communicate by sending and receiving events [OK]

Hint: Event-driven means parts talk by sending/listening events [OK]

Common Mistakes:

• Confusing event-driven with database storage
• Thinking it handles UI design
• Assuming it processes HTTP requests directly

2. Which annotation is used in Spring Boot to mark a method as an event listener?

easy

A. @EventHandler

B. @Listener

C. @HandleEvent

D. @EventListener

Solution

1. Step 1: Recall Spring Boot event listener annotation

   Spring Boot uses @EventListener to mark methods that listen for events.

2. Step 2: Check other options

   @EventHandler, @Listener, and @HandleEvent are not valid Spring Boot annotations for event listening.

3. Final Answer:

   @EventListener -> Option D

4. Quick Check:

   @EventListener marks event methods [OK]

Hint: Remember: @EventListener listens to events in Spring Boot [OK]

Common Mistakes:

• Using @EventHandler which is not a Spring Boot annotation
• Confusing with @Listener or @HandleEvent which don't exist
• Misspelling the annotation name

3. Given this Spring Boot event publishing code snippet, what will be printed?

public class MyEvent extends ApplicationEvent {
    public MyEvent(Object source) { super(source); }
}

@Component
public class Publisher {
    @Autowired
    private ApplicationEventPublisher publisher;

    public void publish() {
        publisher.publishEvent(new MyEvent(this));
    }
}

@Component
public class Listener {
    @EventListener
    public void onMyEvent(MyEvent event) {
        System.out.println("Event received");
    }
}

medium

A. Event received

B. No output

C. Compilation error

D. Runtime exception

Solution

1. Step 1: Understand event publishing

   The Publisher publishes a MyEvent instance using ApplicationEventPublisher.

2. Step 2: Understand event listening

   The Listener class has a method annotated with @EventListener that listens for MyEvent and prints "Event received".

3. Final Answer:

   Event received -> Option A

4. Quick Check:

   Publishing triggers listener print = Event received [OK]

Hint: Publishing event triggers listener print statement [OK]

Common Mistakes:

• Thinking no output because listener is missing
• Assuming compilation error due to event class
• Expecting runtime exception without error

4. What is wrong with this Spring Boot event listener code?

@Component
public class MyListener {
    @EventListener
    public void handleEvent(String event) {
        System.out.println("Event: " + event);
    }
}

medium

A. EventListener methods cannot accept String as event parameter

B. Missing @Component annotation

C. Method must return a value

D. EventListener annotation is misspelled

Solution

1. Step 1: Check event parameter type

   Spring events can be any object, including String, but using String as event parameter is discouraged because it may cause ambiguity and unintended triggers.

2. Step 2: Understand best practice

   Using custom event classes extending ApplicationEvent or plain objects is preferred for clarity and to avoid conflicts.

3. Final Answer:

   EventListener methods cannot accept String as event parameter -> Option A

4. Quick Check:

   String event param is invalid for event listener [OK]

Hint: EventListener needs custom event class, not String [OK]

Common Mistakes:

• Thinking @Component is missing
• Believing method must return a value
• Assuming annotation is misspelled

5. You want to build a Spring Boot app where multiple components react to a user registration event asynchronously. Which approach best fits the event-driven architecture pattern?

hard

A. Send HTTP requests manually between components

B. Call all components directly from the registration method without events

C. Create a UserRegisteredEvent class, publish it with ApplicationEventPublisher, and have multiple @EventListener methods handle it

D. Use a database trigger to notify components

Solution

1. Step 1: Identify event-driven pattern usage

   Creating a custom event class and publishing it allows decoupled communication between components.

2. Step 2: Understand asynchronous handling

   Multiple @EventListener methods can react independently and asynchronously to the event.

3. Step 3: Evaluate other options

   Direct calls, database triggers, or manual HTTP requests do not follow Spring Boot event-driven best practices.

4. Final Answer:

   Create a UserRegisteredEvent class, publish it with ApplicationEventPublisher, and have multiple @EventListener methods handle it -> Option C

5. Quick Check:

   Custom event + publisher + listeners = Create a UserRegisteredEvent class, publish it with ApplicationEventPublisher, and have multiple @EventListener methods handle it [OK]

Hint: Use custom event class and @EventListener for async reactions [OK]

Common Mistakes:

• Calling components directly, losing decoupling
• Relying on database triggers for app events
• Manually sending HTTP requests between components