Observer Pattern — How Spring Events Use It

The Observer pattern decouples a publisher from its consumers. When an order is placed, instead of OrderService directly calling emailService.send(), inventoryService.reduce(), and analyticsService.record() — creating hard dependencies on all three — it publishes an OrderPlacedEvent. Listeners react independently, and adding a new side effect means adding a new class, not editing the publisher.

Spring implements this through ApplicationEventPublisher and @EventListener. The publisher injects the event publisher and calls publishEvent(). Any @Component with a matching @EventListener method is automatically registered — no manual subscribe/unsubscribe ceremony. The IoC container handles discovery through component scanning.

The Spring-specific enhancement that matters most in production is `@TransactionalEventListener`. Regular @EventListener fires during the transaction — if the transaction later rolls back, the email has already been sent. @TransactionalEventListener(phase = AFTER_COMMIT) fires only after the transaction commits successfully. The catch is that it silently drops events when there's no active transaction, which trips up teams who forget to annotate the publisher method with @Transactional.

For non-blocking processing, @Async moves listener execution to a thread pool. The publisher returns immediately. But Spring events are in-process and in-memory — if the app crashes mid-processing, the event is lost. For cross-service events or guaranteed delivery, you need Kafka or a transactional outbox. Spring Events are the right tool for within-service decoupling.