There's No One-Size-Fits-All Tool, Only the Right Choice: Building Notification 2.0 with Spring Statemachine

KakaoBank's notification sending system goes through multiple stages—reception, scheduling, filtering, sending, and reprocessing—and requires accurate management of the state of each message. States such as RECEIVED, SENT_SUCCEEDED, and SENT_FAILED needed to be clearly defined, and each transition also had to trigger follow-up actions such as delivery confirmation or failure notifications.

To handle these complex transition rules, the team also considered implementing an FSM(Finite State Machine) directly, managing per-state transition paths with a Map and writing all pre- and post-transition logic by hand. However, as the system grew, this approach placed an increasing burden of maintenance. While it reduced framework dependency, it also meant the team had to take full responsibility for the systematic structure and scalability of state management on their own.

The team then adopted Spring Statemachine, defining states and events as enums and configuring the initial state, transitions, Guards, and Actions based on StateMachineConfigurerAdapter. In particular, rather than exposing Guard and Action directly, they wrapped them once in internal interfaces to uphold the DIP(Dependency Inversion Principle), lowering coupling while keeping open the possibility of swapping out the framework later.

In the implementation, necessary data such as message IDs were carried in the Header of event messages, to be retrieved and used within Guards or Actions. The state machine instances were also persisted to Redis to keep state consistent across a distributed environment, using StateMachineService together with RedisPersistingStateMachineInterceptor.

As a result of the adoption, the state transition logic became much clearer and development productivity improved, but the learning cost and constraints of the framework itself were also evident. In particular, issues not covered by the framework had to be managed separately, such as the problem that since there is no default TTL, state machine instances remain in Redis indefinitely unless explicitly deleted.

The conclusion is clear. Spring Statemachine is a powerful tool for systematizing complex state management, but it isn't the right answer for every situation. What matters most isn't how many features a tool has, but choosing the tool that fits the scale and context of the problem at hand.