One event bus vs. a middleware translation chain

One event bus wins because middleware integration doesn't add cost linearly - it compounds. Point-to-point wiring needs a mapping for every pair of systems that talk, and an enterprise service bus centralizes those mappings into a chain of translations you maintain forever. A single event stream inverts it: each service publishes its domain events once, and every consumer projects only the fields it needs. You swap mapping sprawl for schema-versioning discipline.

Why does middleware integration decay into a translation chain?

Point-to-point starts innocently. Order capture needs stock levels, so you build one feed. Stock has to tell delivery what shipped, so you build another. Each feed is a mapping - a translation between two schemas that encodes what one side calls a product and what the other expects to receive. The trouble is the arithmetic. Connect n systems that all need to talk and the number of possible pairs trends toward n(n-1)/2; even a modest route-to-market estate - order capture, stock, pricing, loyalty, returnables, delivery, analytics and the SAP financial core - is dozens of live mappings before you multiply by environments.

An enterprise service bus is sold as the cure. Instead of point-to-point, everything routes through the bus and the bus holds the transforms. But that doesn't remove the mappings; it relocates them into one tier and gives them an owner. Order-to-SAP, SAP-to-loyalty, loyalty-to-returnables - each translation still exists, now as a flow inside the middleware, and each still encodes assumptions about the other side's fields. Change a product code and you go hunting through flows to find every transform that touched it. That is the chain: a long line of point translations, any link of which can quietly break the numbers downstream.

And you rent the chain by throughput. Per integrate.io's pricing analysis, MuleSoft lists from roughly $1,250 per vCore per month as of early 2026, and one documented Platinum arrangement runs $210,000 a year for four vCores. The same analysis puts Forrester's composite for a $7.5B organization at about $600,000 a year in license alone, with first-year total cost commonly landing at two to three times the subscription once build and specialist labor are counted. None of that spend buys new capability - it maintains translations between systems that already exist.

What does one event stream change?

The event model inverts ownership of the translation. A service publishes a domain event - order placed, stock reserved, delivery confirmed - once, describing what happened in its own language, and it neither knows nor cares who consumes it. Consumers subscribe and project only the fields they need into their own store. There is no order-to-loyalty mapping and no loyalty-to-order mapping; there is one order-placed event and a loyalty projection that reads three fields from it. Add a new consumer and the producer never finds out.

That collapses the arithmetic. Instead of a transform per pair, you keep one published contract per producer and one projection per consumer - the count grows with systems, not with pairs. At brewer scale the difference is existential: one of the world's largest brewers has publicly documented connecting more than 4,500 business-critical applications and moving to an event-driven backbone. At 4,500 endpoints, per-pair translation is not a maintenance nuisance; it is an unpayable tax, and publish-once is the only arithmetic that survives.

What replaces the mappings is governance of contracts. A schema registry holds each event's shape and its versions; producers evolve those schemas under agreed rules; consumers validate against the contract they subscribed to. You stop maintaining transforms and start maintaining compatibility - a smaller and far more visible surface. We run the whole route-to-market suite - order capture, stock, loyalty, returnables, delivery and analytics - on one event bus with this shape, which is why the comparison below is not academic to us.

Doesn't the bus just move the coupling somewhere else?

Partly, yes - and pretending otherwise is how event projects go wrong. The stream does not delete coupling; it moves it from runtime wiring into schema contracts. Version an event carelessly and the registry becomes the new chain: a breaking change to order-placed ripples out to every consumer that read the field you removed, and now you are hunting downstream projections instead of upstream flows. There is a subtler version of the same failure, where a well-meaning team pushes transformation logic back into a shared layer on the bus and rebuilds the middleware everyone just left, one convenient central mapping at a time.

The mitigations are unglamorous and non-negotiable: additive-only schema evolution, explicit event versioning, consumer-driven contract tests, and a dead-letter path for events that fail validation. With them, a producer can change its schema without booking a coordination meeting with every downstream. Without them, you have rebuilt the translation chain inside your topics and thrown away the one property that made the move worth doing.

How do you move from a translation chain to one event stream?

This is a migration, not a big-bang cutover, and it has a fairly reliable order of operations.

1. Count the pairs, not the systems. Inventory every transform in the current ESB and point-to-point estate and count mappings, not endpoints. That number is your baseline; it is also the maintenance line a cost-to-serve model turns into a figure you can defend in a budget review.
2. Model domain events, not integration messages. Define events around what the business does - order placed, stock reserved, empty returned - owned by the producing service and expressed in its own language, not pre-shaped to please one specific downstream.
3. Stand up the schema registry before the first topic. Contracts come before traffic. Decide your versioning rule - additive-only is the safe default - and your compatibility policy while the diagram is still cheaper to change than the code.
4. Strangle the chain, don't rip it out. Route new events onto the bus while the ESB still carries legacy flows, then retire mappings one consumer at a time. The same strangler-fig approach we use to replace a commerce stack while it runs applies cleanly to integration.
5. Leave SAP where it is. The financial core does not need to be event-native. Give it a single projection that consumes the events it cares about, and delete the dozen point-to-point feeds that previously kept it in sync.
6. Measure mappings retired, not features shipped. The win is throughput you stop renting and transforms you stop maintaining, so track that directly - it is the number that justifies the programme long before any new feature ships.

The argument that event-driven beats middleware is largely settled at brewer scale; the 4,500-application estates have already voted with their architecture. The open question for 2026 is governance - whether an organization can version schemas as rigorously as it once change-controlled firewall rules. Teams that treat the registry as a first-class product, with owners, deprecation windows and contract tests, will keep the publish-once advantage; the ones that don't will rediscover the translation chain with better dashboards. That discipline, not the choice of broker, is what a serious build-versus-buy decision should be weighing this year.