Don't Panic — Enterprise Service Buses

An enterprise service bus, or ESB, is the diplomatic corridor between applications that were never particularly keen to share a building. Rather than making every system learn every other system's protocol, address, and message dialect, each one meets the bus at an adapter. The bus takes care of the travel arrangements: routing, format changes, protocol bridges, and the policy checks around the trip.

Before this arrangement, integration often became a dense web of direct links. Add one system and somebody had to negotiate with several existing systems, each in its own ceremonial costume. The ESB reduces that connection burden by putting mediation in one place. It does not make the differences disappear. It merely ensures they have a shared address, which is progress, though not the sort that lets anyone stop writing tests.

The key idea is mediation: the work between a producer and a consumer. It can choose a destination, translate a message, add integration context, or apply transport security. The companion idea is the contract. A mapping is not harmless plumbing when one field is optional in one system, uses a different code list in another, or carries a different assumption about time. Someone must own that decision, name the supported version, and keep examples that prove the route handles more than its favorite message.

Here is the trapdoor. A bus can validate a message field, but it should not become the place that decides whether an order is valid or inventory can be reserved. Those are domain decisions, and the service that owns the domain must keep them. Otherwise the integration layer quietly grows a second application inside it, wearing a moustache and claiming it is only a route.

Delivery has its own small galaxy of paperwork. A synchronous call needs a timeout and retry rule. A durable message needs persistence, acknowledgement, duplicate handling, expiry, and somewhere useful to send exhausted work. The bus can participate in those rules, but it cannot magically decide the end-to-end effect for the services involved.

Continue with the Intro for the architecture and boundaries. Use Slides for the decision map, then the Cheatsheet when reviewing a route. The practice reference turns the ideas into a design worksheet, and the exercise asks you to make the ownership, failure path, and evidence visible. That is the job: not an enormous central brain, but explicit mediation that can be changed, observed, and recovered.