The event log as source of truth: why event-driven beats point-to-point integration
How shifting from bilateral API calls to a shared event journal simplifies system coupling and removes the fragility of double-writes.
When a company runs several systems - CRM, warehouse, accounting, online store - the question of how they share data comes up early. The first answer is almost always the same: when system A changes something, it calls system B. That feels simple when there are two or three systems involved.
When the count reaches six or seven, the web of bilateral calls becomes a permanent source of pain - and treating integration as a discipline rather than a side-effect is the starting point for addressing it. One system is down and the others do not know what to do with the error. Data was written in one place but not in another. Reconstructing the sequence of events after a failure is impossible because each system only keeps its own slice.
What the event model is
An idea that is gaining traction in engineering circles is storing the history of changes rather than current state. Instead of every system calling all interested parties on every change, it writes an event to a shared log. Other systems read the log and react to what matters to them.
An event is a fact: "order created", "payment received", "inventory level changed". It is immutable. It happened - and that is recorded. The current state of any object is the result of applying all the events that have occurred to it. Whether a small lag in receiving those events is acceptable depends on context - the question of when a business actually needs streaming versus 15-minute batches is worth asking before committing to the model.
This approach is called event sourcing, and it is not new. But right now enough tooling is appearing to make it practical at the product team level, not just inside financial trading systems.
What this gives you in practice
When the log is the source of truth, several things become easier.
Recovery after failure is one of them. If a system was down for a few hours and missed events, it simply reads the log from where it left off. Nothing is lost, order is preserved.
Audit becomes free. The question "what happened to this order and when" no longer requires a manual investigation - the history is already in the log.
Adding a new system does not require changes to existing ones. A new consumer just starts reading the log. None of the existing systems knows about it or needs to call it.
Where the model works less well
The event model is not a silver bullet. It adds complexity where there was none before.
If you need the current state of an object, you either have to replay the full log every time or build and maintain separate projections (snapshots). That is extra work.
Event schema requires discipline. If today an event is called "order_created" with one set of fields, and six months later someone changes the structure without versioning, old consumers break.
For simple CRUD systems where interactions are not complex and audit does not matter, the model is overkill.
How to think about this when designing
I look at the event model not as a mandatory architecture but as a tool to apply in specific situations.
A few questions that help make the call:
- Do we have several systems that need to know about the same changes?
- Do situations arise where data was written in one place but never reached another?
- Do we need a history of changes - for audit, debugging, or analytics?
- Do we frequently add new systems or integrations?
- How critical is real-time consistency - or is a small lag acceptable?
If the answer to most of these is yes, the event log is worth considering as the central mechanism rather than a supporting one.
The transition is neither quick nor free. But companies that have made it rarely want to go back to the web of point-to-point calls.