Spring Application Events.

What it is

Spring Application Events are an in-process notification system. A publisher announces a fact, a listener reacts, and a multicaster (the dispatcher) fans one event out to many listeners. A technical term you will hear is payload event: since Spring 4.2, you can publish a plain object, and Spring wraps it for you behind the scenes.

How it works under the hood

You publish: code calls publishEvent(...) on ApplicationEventPublisher.
Spring hands it to the multicaster: by default this is SimpleApplicationEventMulticaster, which finds all matching listeners.
Spring matches by type: listeners declared for that event class, its super types, or annotated @EventListener methods are considered.
Spring invokes listeners: by default they run synchronously, meaning in the same thread and before publishEvent returns.
Exceptions matter: if a synchronous listener throws, the exception goes back to the caller and later listeners may not run.
Optional async: if you enable async execution and mark a listener with @Async, the event work moves to a separate thread and the publisher returns sooner.

When and why to use it

Use events for loose coupling inside one application: audit logging, cache updates, sending email, publishing domain facts, or reacting to startup events like ApplicationReadyEvent.
Do not use events when the caller must know the result immediately, when you need durable delivery, or when another service must receive the message even if this JVM dies.
Use @TransactionalEventListener when a side effect must happen only after the database commit succeeds. A transaction is a unit of work that either fully commits or rolls back.

Events vs direct calls vs message brokers

Approach	Best for	Coupling	Delivery
Direct call	Simple flow	High	Immediate
Spring event	Same app	Low	Same JVM
Kafka/RabbitMQ	Cross-service	Low	Durable

Performance and edge cases

Publishing is usually O(n) in the number of matching listeners, because Spring must check and invoke each one. Space overhead is tiny, roughly O(1) beyond the event object itself. The real cost is listener work: if one listener spends 200 ms calling an external API and you have three such listeners, the publisher may block for hundreds of milliseconds. That is why a seemingly harmless event can become a latency trap.

A practical rule: keep synchronous listeners short and side-effect light. If you need background processing, use an executor with a bounded thread pool. In real systems, a small pool like 8 to 16 threads is common for light I/O work, but the exact size should match your CPU and downstream latency. Also remember ordering: @Order controls listener order, with smaller values running first.

Important gotcha: Spring events are not a queue. There is no built-in retry, no persistence, and no cross-process delivery. If the app restarts, the event is gone. That is the key difference interviewers want you to say out loud.

// src/main/java/com/example/appevents/DemoApplication.java package com.example.appevents; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; @SpringBootApplication public class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } } // src/main/java/com/example/appevents/OrderPlacedEvent.java package com.example.appevents; import java.math.BigDecimal; import java.time.Instant; // A plain object is enough: since Spring 4.2, any object can be published as an event. public record OrderPlacedEvent(String orderId, BigDecimal amount, Instant occurredAt) {} // src/main/java/com/example/appevents/OrderService.java package com.example.appevents; import org.springframework.context.ApplicationEventPublisher; import org.springframework.stereotype.Service; import java.math.BigDecimal; import java.time.Instant; import java.util.Map; import java.util.concurrent.ConcurrentHashMap; @Service public class OrderService { private final ApplicationEventPublisher publisher; private final Map<String, BigDecimal> orders = new ConcurrentHashMap<>(); public OrderService(ApplicationEventPublisher publisher) { this.publisher = publisher; } public String placeOrder(String orderId, BigDecimal amount) { // Validate input before publishing. Events are for reactions, not for basic input checks. if (orderId == null || orderId.isBlank()) { throw new IllegalArgumentException("orderId must not be blank"); } if (amount == null || amount.signum() <= 0) { throw new IllegalArgumentException("amount must be greater than zero"); } // In a real app, this would usually be inside a database transaction. // If a synchronous listener fails, the response fails too, and without a transaction // your earlier work may already be visible. orders.put(orderId, amount); publisher.publishEvent(new OrderPlacedEvent(orderId, amount, Instant.now())); return orderId; } public BigDecimal findAmount(String orderId) { return orders.get(orderId); } } // src/main/java/com/example/appevents/OrderController.java package com.example.appevents; import org.springframework.http.ResponseEntity; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PathVariable; import org.springframework.web.bind.annotation.PostMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; import java.math.BigDecimal; import java.util.Map; @RestController @RequestMapping("/orders") public class OrderController { private final OrderService orderService; public OrderController(OrderService orderService) { this.orderService = orderService; } @PostMapping("/{orderId}") public ResponseEntity<Map<String, Object>> place(@PathVariable String orderId, @RequestParam BigDecimal amount) { String id = orderService.placeOrder(orderId, amount); return ResponseEntity.accepted().body(Map.of( "orderId", id, "status", "submitted" )); } @GetMapping("/{orderId}") public ResponseEntity<Map<String, Object>> get(@PathVariable String orderId) { BigDecimal amount = orderService.findAmount(orderId); if (amount == null) { return ResponseEntity.notFound().build(); } return ResponseEntity.ok(Map.of( "orderId", orderId, "amount", amount )); } } // src/main/java/com/example/appevents/OrderEventListeners.java package com.example.appevents; import org.springframework.boot.context.event.ApplicationReadyEvent; import org.springframework.context.event.EventListener; import org.springframework.core.annotation.Order; import org.springframework.stereotype.Component; @Component public class OrderEventListeners { @EventListener @Order(1) public void audit(OrderPlacedEvent event) { // Side-effect 1: a cheap listener is a good fit for synchronous events. System.out.println("[audit] order=" + event.orderId() + ", amount=" + event.amount()); } @EventListener @Order(2) public void rejectSuspiciousOrders(OrderPlacedEvent event) { // Edge case: if a synchronous listener throws, the publisher sees the failure. // This is exactly why you should keep listener logic small and predictable. if (event.orderId().toLowerCase().startsWith("bad")) { throw new IllegalStateException("Rejected by business rule for orderId=" + event.orderId()); } } @EventListener(ApplicationReadyEvent.class) public void onAppReady() { System.out.println("[boot] ApplicationReadyEvent received: the application context is fully started."); } } // src/main/java/com/example/appevents/ApiExceptionHandler.java package com.example.appevents; import org.springframework.http.ResponseEntity; import org.springframework.web.bind.annotation.ExceptionHandler; import org.springframework.web.bind.annotation.RestControllerAdvice; import java.util.Map; @RestControllerAdvice public class ApiExceptionHandler { @ExceptionHandler(IllegalArgumentException.class) public ResponseEntity<Map<String, String>> handleBadRequest(IllegalArgumentException ex) { return ResponseEntity.badRequest().body(Map.of("error", ex.getMessage())); } }

Follow-up & Tricky Questions:

How is @EventListener different from ApplicationListener? @EventListener is annotation-based and easier to read, while ApplicationListener is an interface with more explicit typing. Both can work for the same event system.
Are Spring events async by default? No. They are synchronous by default, so the publisher waits for listeners unless you explicitly move work to an async executor.
How do you make an event run after a database commit? Use @TransactionalEventListener, usually with the default AFTER_COMMIT phase. That way the listener only reacts if the transaction really succeeds.
Can multiple listeners handle the same event? Yes, and that is one of the main benefits. Use @Order if a specific sequence matters, but keep in mind ordering only helps for synchronous listeners in the same JVM.
When should I use events instead of Kafka or RabbitMQ? Use Spring events for internal coordination inside one app. Use a broker when you need durability, retries, buffering, or cross-service delivery.
Tricky: Does publishEvent guarantee the work is finished when it returns? Only for synchronous listeners. If a listener is async, the publisher returns before the listener work completes.
Tricky: If one listener fails, do the others still run? In synchronous mode, a thrown exception can stop the chain and fail the caller. In async mode, the publisher may already have returned, so the failure is handled on the executor thread.
Tricky: Can I publish any object, or only classes that extend ApplicationEvent? Since Spring 4.2, any object can be published. Spring treats it as an event payload and routes it to matching listeners.