Addressing Service Decomposition Challenges with Event‑Driven Architecture in Transaction Systems

The transaction system transitioned from a monolithic architecture to a service‑oriented approach, allowing domain‑specific microservices to improve scalability and enable multiple teams to maintain distinct domain services. However, complex business processes requiring many microservices lead to tight coupling, consistency challenges, reduced availability, and long response times, especially when synchronous RPC calls are used (e.g., order cancellation with refund processing).

State explosion arises as the order status machine becomes increasingly complex, with nested and combined state machines generating a Cartesian product of states that are hard to maintain and understand. This is common in scenarios like hotel transaction systems where order and payment states operate in parallel.

To mitigate these issues, the system introduces an event mechanism that separates synchronous state operations from asynchronous event handlers. Events are reliably distributed, ensuring eventual consistency across microservices and reducing the need for distributed transactions. The event‑driven model expands the traditional single‑field state machine to handle real‑world business complexity.

Reliability is achieved using the in‑house QMQ reliable message queue. Producers commit business operations and message persistence within a local transaction, only deleting the message after successful broker delivery. Brokers retain messages until consumers acknowledge them, guaranteeing that business actions tied to messages are eventually executed, simplifying distributed transaction handling.

The core StoreEngine handles order data updates and emits change events containing modified fields. All business services listen to these events, allowing them to react independently. This decouples the core system from business logic, enhancing extensibility and isolation; new services can be added by registering listeners for relevant events.

Because StoreEngine events are business‑agnostic, the ActorEngine framework translates them into business‑specific events. ActorEngine registers actors with corresponding business events, executes them reliably, and splits complex event listeners into smaller, manageable units, reducing retry costs and simplifying development.

In summary, the transaction system faces complex workflows, distributed consistency, and state‑machine explosion. By adopting an event‑driven architecture, order field changes trigger events that drive business processes, achieving decoupling, isolation, and simplifying consistency to eventual consistency. The implementation uses a stable core event producer and the ActorEngine to convert generic events into business events, while a visualization tool aids developers in understanding event sequences.