Glossary
A software design pattern where system components communicate by producing and reacting to events — state changes, like “order placed” or “payment failed” — asynchronously, rather than through direct, synchronous calls between services.
Why It Matters
Direct service-to-service calls create tight coupling: if one service is slow or down, every service calling it directly feels the impact immediately. Event-driven systems let services react to what happened without needing to know or wait on each other, which is what makes large, multi-service platforms resilient instead of fragile.
This is part of our Digital Platforms capability — the architecture that lets one platform serve every user type a business has, instead of a separate codebase per department.
See the full Digital Platforms capabilityDoes this make a system harder to debug?
It can — tracing a single business process across multiple asynchronous event handlers requires more deliberate observability tooling than following a single synchronous call chain. That tradeoff is usually worth it at the scale where event-driven architecture becomes necessary.
What's a simple example of this in practice?
A checkout completing might emit an 'order placed' event that separately triggers inventory update, confirmation email, and analytics logging — each handled by a different service, none of which need to call each other directly or wait for one another to finish.