Why choose an event-driven architecture? What advantages does the decoupling buy you?

Decoupling services through events makes the system more scalable, more responsive/real-time, and easier to develop and maintain — because services stop depending directly on each other.

The problem EDA solves: in a microservice system, communication that is too tightly coupled (or even too loosely coupled) makes the system costly and difficult to build and maintain. Publishing/subscribing to events instead of calling directly yields three concrete wins:

• Decoupling — a service can change, fail, or scale without its neighbours needing to know; teams develop and deploy independently.
• Scalability — decoupled tasks can be processed in parallel and each service scaled on its own.
• Real-time responsiveness — asynchronous reactions to events allow more real-time processing instead of everything waiting in a synchronous chain.

The payoff is modular growth plus clear, auditable traces — ideal for complex financial workflows where flexibility and reliability both matter.

Go deeper:

• Publish–subscribe pattern (Wikipedia) — the messaging pattern behind the decoupling: publishers never need to know who, if anyone, is subscribed.