Key Considerations and Best Practices for Using Spring Event in Production

1. Graceful Shutdown Is a Prerequisite for Using Spring Event

Spring broadcasts events by locating listeners in the ApplicationContext , which requires getBean . During the shutdown phase of the ApplicationContext , getBean is prohibited; publishing events at this time throws errors. Our production incident, caused by this restriction, highlighted the need to cut off inbound traffic (HTTP, MQ, RPC) before closing the Spring context.

2. Event Loss During Service Startup

In our system, a Kafka consumer started consuming in the init-method phase, while Spring registered @EventListener beans later. Consequently, events published by the consumer could not find listeners, leading to lost messages. The solution is to defer traffic until after Spring has fully refreshed, e.g., by using SmartLifecycle or listening for ContextRefreshedEvent before opening entry points.

3. Strong‑Consistency Scenarios Are Unsuitable for Publish‑Subscribe

Business cases that require strict atomicity—such as order placement with inventory deduction—cannot rely on Spring Event because the framework does not provide a built‑in mechanism for rolling back when a subscriber fails.

4. Event‑Driven Architecture Fits Eventual‑Consistency Scenarios

When business logic can tolerate retries (e.g., post‑order processing, releasing locks, notifying settlement systems), Spring Event cleanly decouples components. Each subscriber can operate independently, and failures can be retried until success.

5. Ensuring Reliability When Using Spring Event

Publish events with applicationContext.publishEvent(event) . If a subscriber throws an exception, the publish call propagates the error, allowing the publisher to detect failure. Three reliability patterns are recommended:

Subscriber‑Side Retry : Use Spring Retry (e.g., @Retryable ) so the failing method is automatically retried.

Kafka Consumer Retry : Let the consumer return a failure to Kafka, which will redeliver the message.

Fault Reporting to a Management Platform : After exceeding retry limits, send a fault message to a dedicated MQ; a fault‑management service records the issue and provides a manual retry interface.

Example of a retryable subscriber:

@Retryable(value = Exception.class, maxAttempts = 3, backoff = @Backoff(delay = 100L, multiplier = 2))
public void performSuccess(PerformEvent event) {
    // business logic
}

Remember to add the spring-retry dependency:

<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
    <version>1.2.4.RELEASE</version>
</dependency>

6. Subscribers Must Be Idempotent

Because retries re‑execute all listeners, each listener must handle duplicate executions safely to avoid data inconsistency.

7. Why Use Spring Event Even When MQ Exists

Message queues excel at inter‑service communication and isolation, while Spring Event is lightweight and ideal for intra‑application decoupling. They complement each other: use MQ for cross‑service events and Spring Event for internal, fine‑grained coordination.