Architecture Pattern
Event-Driven Architecture
Systems communicate by publishing and reacting to events — 'this happened' — instead of directly calling each other and waiting for a response.
What it is
Instead of System A calling System B directly and waiting, System A publishes an event ('order created') that any interested system can react to independently. This decouples systems from each other — they don't need to know who's listening, only what happened.
When to use it
When multiple systems need to react to the same change independently, or when you want systems to keep working even if one downstream consumer is temporarily down.
Real tradeoffs
- —Decouples systems well, but makes the overall flow harder to trace — 'what happens when an order is created' is no longer in one place
- —Requires real infrastructure (a message queue or event bus) and monitoring to know events are actually being processed
- —Overkill for a simple, linear process with one clear next step — a direct call is simpler and easier to debug there
Related
Have a project in mind?
Tell us what you're trying to automate or build — we'll reply with next steps, not a sales pitch.