Spring Application Events.

Hook: Spring events are like a school bell: one ring can wake up many people, and the caller does not need to know who responds.

Question: What are Spring Application Events?

Answer: Spring Application Events are Spring’s built-in way to announce that something happened inside the app, such as “order placed” or “application ready.” A publisher sends the event, and one or more listeners react without the publisher calling them directly. In Spring Boot, you usually publish with ApplicationEventPublisher and receive with @EventListener.

Interview-Ready Answer: “I use Spring application events when I want loose coupling inside one Spring application. One component publishes an event, and any matching listener can react without a direct dependency. By default it is synchronous, so the publisher waits for listeners in the same thread. That is simple and fast, but it is not a message broker. If I need after-commit behavior or background work, I use @TransactionalEventListener or @Async with a proper executor.”

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

1. You publish: code calls publishEvent(...) on ApplicationEventPublisher.
2. Spring hands it to the multicaster: by default this is SimpleApplicationEventMulticaster, which finds all matching listeners.
3. Spring matches by type: listeners declared for that event class, its super types, or annotated @EventListener methods are considered.
4. Spring invokes listeners: by default they run synchronously, meaning in the same thread and before publishEvent returns.
5. Exceptions matter: if a synchronous listener throws, the exception goes back to the caller and later listeners may not run.
6. 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

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.

Real-world story: Imagine a checkout service in an e-commerce app. When an order is placed, the service publishes OrderPlacedEvent. One listener writes an audit record, another reserves inventory, and another sends a confirmation email. This is a great fit because the checkout code stays clean and does not need to know every side effect.

Now the bug story: a team assumed events were “background by default” and put a slow HTTP call to an email provider inside a synchronous listener. During a sale, checkout latency jumped from about 120 ms to over 2 seconds, Tomcat request threads piled up, and users started seeing timeouts. In logs, the team saw the request thread blocked inside the event listener, which looked like the checkout endpoint was slow even though the real problem was hidden in the listener.

A different outage comes from a failing listener. If one listener throws an exception, the whole publish call fails in synchronous mode. Users may see a 500 after clicking “Place order,” and the database row may already exist if you are not inside a proper transaction. That is why good teams treat events as a coordination tool, not as a magic safety net.

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.

Common Mistakes:

• Thinking events are async by default. Correction: they are synchronous unless you configure async execution and annotate the listener appropriately.
• Putting slow network calls in sync listeners. Correction: keep sync listeners short; move heavy work to async or a broker.
• Using events for cross-service communication. Correction: Spring events are only for the same JVM; use Kafka, RabbitMQ, or similar for service-to-service messaging.
• Forgetting transaction boundaries. Correction: if side effects must follow a successful commit, use @TransactionalEventListener rather than a plain listener.

Memory Hook: Think of a school bell: one ring goes to many rooms. If the rooms are in the same building, the bell is enough; if they are in different buildings, you need a courier, not a bell.

Cheat Sheet:

• Publisher announces a fact; listeners react.
• Default dispatch is synchronous and in-process.
• Cost is about O(n) in matching listeners.
• Use @EventListener for simple reactions.
• Use @TransactionalEventListener after commit.
• Use a broker for durability and cross-service delivery.

Practice Tasks:

• Add a second listener that records the event timestamp into a list, then confirm both listeners run.
• Mark one listener with @Async and observe that the HTTP response returns before the listener prints.
• Replace the in-memory map with a database transaction and move a side effect to @TransactionalEventListener after commit.