Test Insight — Why your event bus became a distributed monolith
The promise of the event bus was decoupling. What most teams get instead is a monolith with a network hop bolted into the middle of it — all the coordination cost of the original system, plus a serialization tax.
Test Rahman
Principal Engineer, Platform
The tell
You can spot it in the deploy order. If service C must ship before service B, and B before A, the services are not independent — they are modules that happen to be separated by a broker.
How it happens
Almost always the same way: teams publish commands instead of facts. "ChargeCustomer" is a command; it names what the consumer must do, so the producer now owns the consumer's behaviour. "PaymentAuthorized" is a fact; the consumer decides what it means.
Once commands are on the bus, every new consumer is a negotiation with the producer, and the coupling you were trying to remove has simply moved into the schema registry.
The fix is boring
Publish facts. Version them additively. Make consumers idempotent and replayable, so a bad deploy is recovered by replaying the log rather than by a coordinated rollback across four teams.
None of this is novel. It is just unglamorous enough that it tends to lose the argument to whichever framework is trending that quarter.
Test Rahman
Principal Engineer, Platform
Test Rahman leads platform engagements at Ternary — the ones where the architecture has to hold up under regulatory audit and a traffic spike in the same quarter.
Before Ternary he spent eight years in payments infrastructure, where an outage is measured in lost revenue per second, and four building trading systems where it is measured in microseconds.
Related reading
All insightsMore from the engineering studio.
Have an event bus that outgrew its design?
Talk to the engineers who would actually run the build — not a sales layer in front of them.