Observer Pattern vs EventListener vs Spring Events

Direct Answer

Java listener APIs and Spring application events are Observer-style mechanisms: producers publish or signal an event and registered handlers react through a common contract. Spring uses an application event multicaster and dependency injection rather than a subject directly storing each concrete listener. Delivery is synchronous by default but configurable; transaction-bound and asynchronous listeners have different failure and consistency rules.

Deep Dive & Architecture

Java's listener interfaces are a direct Observer-style API: a source accepts listeners and invokes their callback when an event occurs.

Spring application events add an intermediary managed by the container. ApplicationEventPublisher hands an event to the application event multicaster, and methods registered with @EventListener are selected by type. The publisher does not need references to concrete listeners. With the default multicaster, listeners run in the publishing thread; executor-backed or @Async handling changes timing and exception behavior.

@TransactionalEventListener binds a listener to a transaction phase and defaults to AFTER_COMMIT. It normally requires an active transaction unless fallback execution is enabled. An after-commit callback still does not make a database change and an external message atomic; use an outbox or another reliability pattern when that guarantee matters.

Code Example

@Service
class CartService {
    private final ApplicationEventPublisher publisher; // subject
    private final CartRepository repo;
    CartService(ApplicationEventPublisher publisher, CartRepository repo) {
        this.publisher = publisher; this.repo = repo;
    }

    @Transactional
    public void checkout(Long cartId) {
        var cart = repo.findById(cartId).orElseThrow();
        cart.setStatus(CartStatus.CHECKED_OUT);
        repo.save(cart);
        publisher.publishEvent(new CartCheckedOut(cart.getId())); // notify observers
    }
}

record CartCheckedOut(Long cartId) {} // the data carried to observers

@Component
class PaymentListener {                 // observer (runs in publisher's thread)
    @EventListener
    void onCheckout(CartCheckedOut e) { System.out.println("Pay for " + e.cartId()); }
}

@Component
class InventoryListener {               // observer (runs only after commit)
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    void onCheckout(CartCheckedOut e) { System.out.println("Reserve for " + e.cartId()); }
}

Common Mistakes & Pitfalls

• Assuming @EventListener is async. It's synchronous by default; add @Async (with @EnableAsync) for background work.
• Publishing then reading uncommitted data. A plain listener may run before commit. Use @TransactionalEventListener(AFTER_COMMIT).
• Ignoring exception propagation. In synchronous mode, a listener throwing can stop later listeners; handle errors per listener.
• Thinking Spring events are Pub/Sub. No broker, single JVM — it's Observer.