Why Spring Event Can Lose Messages During Startup and How to Avoid It

Background and Problem

During a production deployment a Kafka consumer processed message A and, after business logic, attempted to publish message B via Spring ApplicationEvent. The B event was not handled for a few seconds after the service started, resulting in silent message loss with no error logs or monitoring traces.

Root Cause Analysis

Spring registers methods annotated with @EventListener in the SmartInitializingSingleton phase, which occurs after bean init‑method execution (the InitializingBean phase). If a bean’s init‑method starts consuming Kafka messages before the @EventListener methods are registered, any events published in that interval are dropped.

Spring Event Lifecycle

Declare an event : Create a class that extends org.springframework.context.ApplicationEvent (optionally generic to carry a payload).

Publish an event : Inject ApplicationContext and call publishEvent(new MyEvent(...)).

Listen to an event : Annotate a method with @EventListener; Spring matches the method parameter type to the event type.

Startup Sequence Details

During container startup the order is: InitializingBean → invokeInitMethod executes the bean’s init‑method. In the example the init‑method registers the consumer with Kafka and begins message consumption. SmartInitializingSingleton → EventListenerMethodProcessor scans all beans, finds @EventListener methods, and registers them with the ApplicationContext.

Because step 1 runs before step 2, any ApplicationEvent emitted inside the consumer’s init‑method (or any code it triggers) can be lost until the listeners are registered. The window widens if the init‑method takes longer (e.g., network time‑outs, partition assignment delays).

<bean id="kafkaConsumer" class="com.example.KafkaConsumer" init-method="init" destroy-method="destroy"/>

Implications

The loss is nondeterministic but becomes more likely under high traffic or when the consumer’s initialization is slow. In production this manifested as a three‑second gap where events were not processed, leading to data loss without any observable exception.

Recommendations

Avoid using Spring ApplicationEvent for critical message flow that may be triggered during bean initialization.

Ensure listeners are registered before any events can be published, e.g., by moving consumer start‑up to a later lifecycle phase (such as ApplicationReadyEvent) or by initializing the consumer after the SmartInitializingSingleton phase.

Consider implementing a custom observer pattern or a dedicated messaging framework that does not rely on Spring’s event registration timing.

In summary, the delayed registration of @EventListener methods relative to bean init‑method execution can cause transient event loss. Developers should either redesign the initialization order or replace Spring Event with a more deterministic mechanism for production‑critical workflows.