Event-driven architecture is genuinely the right answer for some problems and reliably catastrophic for others, and the difference is rarely discussed with the same enthusiasm as the benefits. The costs are real: you trade a stack trace for a correlation id, a transaction for a saga, and a synchronous error for a message that vanished somewhere between two services.
01What you give up
A synchronous call gives you an immediate answer, a stack trace when it fails and a database transaction that either commits or does not. Replace it with an event and all three go away. The caller learns nothing about the outcome, failures surface minutes later in a different service's logs, and consistency becomes eventual whether the business wanted that or not.
None of that is an argument against events. It is an argument for being clear-eyed about the bill, because teams that adopt events for decoupling and then spend a year building tracing, replay tooling and reconciliation jobs have usually paid more than the coupling was costing them.
| Property | Synchronous call | Event |
|---|---|---|
| Outcome known to caller | Immediately | Never, without a callback |
| Failure visibility | Stack trace at the call site | Log entry in another service |
| Consistency | Transactional | Eventual |
| Coupling | Temporal and structural | Structural only |
| Debugging | Follow the stack | Correlate across services and time |
02Where events are the wrong tool
If the caller needs the result to continue, an event is the wrong shape - you will end up building a request-reply pattern on top of a message bus, which is a slower, less debuggable RPC. If the operation must be atomic across services, events give you a saga with compensating transactions, and compensations are much harder to get right than a rollback.
Small teams with a handful of services are the other common mismatch. The decoupling benefit scales with the number of teams that need to deploy independently. With three services and one team, events mostly add indirection and take away the stack trace.
03Where they earn their keep
Fan-out is the strongest case. One thing happens and five unrelated systems care - notifications, analytics, search indexing, audit, billing. Doing that synchronously couples the write path to five dependencies and makes checkout as slow and as fragile as the slowest of them.
Buffering load is the second. A traffic spike that would overwhelm a downstream system becomes a queue that drains at a sustainable rate. And audit trails are the third: an append-only event log answers 'what happened and when' in a way that a mutable table simply cannot.
| Shape | Use | Why |
|---|---|---|
| Caller needs the result | Synchronous | Events add latency and hide failures |
| One writer, many interested readers | Events | Fan-out without coupling the write path |
| Spiky load, tolerant consumer | Events | Queue absorbs the peak |
| Must be atomic | Synchronous + transaction | Sagas are harder than rollbacks |
| Audit and history required | Events | Append-only log is the natural fit |
04The transactional outbox, which is not optional
Writing to your database and publishing an event are two operations that can partially fail. Publish first and you can announce something that never happened; write first and you can commit something nobody hears about. Neither failure is rare enough to ignore.
The outbox pattern fixes it: write the event to a table in the same transaction as the business change, then have a separate process read that table and publish. It is more moving parts, and it is the difference between a system that occasionally lies and one that does not.
05Budget for the tooling on day one
An event-driven system without distributed tracing is very difficult to debug and quite easy to build by accident. Correlation ids propagated through every message, a searchable trace view, dead-letter queues with a replay path, and consumer lag monitoring are not enhancements - they are the minimum for operating the thing.
Cost them into the decision rather than discovering them after the first production incident. Teams that adopt events without this tooling do not get a decoupled architecture; they get a distributed system they cannot see inside.
Topics
Marcus Hale
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer