The enterprise integration patterns that actually survive in production

Most enterprises do not choose their integration architecture. They accumulate it. The enterprise integration patterns you actually run, point-to-point links, a hub-and-spoke ESB, some API-led integration, a few event streams, are the residue of fifteen years of "just connect these two systems for now". This article is an honest comparison of those patterns: when each one holds up under real transaction volume, and when it quietly rots into a maintenance trap.

Point-to-point: the default that never scales

The first integration is always point-to-point. System A needs data from system B, so someone writes a direct connection. It ships in a week and it works.

The problem is arithmetic. Each new system that needs to talk to the others adds connections, not linearly but closer to n-squared. Three systems need three links, ten can need forty-five, and thirty systems in a real telecom or billing landscape produce a connection count nobody can hold in their head.

What this looks like in production:

• No single owner. Each link was built by a different team, in a different year, in a different language. When one breaks at 2am, nobody knows who is on the hook.
• Tight coupling. Change a schema in one system and you do not know how many downstream consumers you broke until they fail.
• No observability. There is no central place to see what flowed where, and reconciliation in a billing context becomes archaeology.

Point-to-point is not wrong. For a stable landscape of three or four systems it is the correct, cheapest answer. It becomes a trap the moment the count climbs and nobody tracks the total: "just connect these two for now" turns into a maintenance cost that grows every quarter.

Hub-and-spoke ESB: removing the spaghetti, recreating the bottleneck

The classic answer to point-to-point sprawl is the Enterprise Service Bus. Instead of every system talking to every other system, each talks only to the bus, which handles routing, transformation and protocol mediation. This is the original promise of EAI, enterprise application integration: one place to govern the flows, collapsing the n-squared problem into n connections.

In practice the ESB solves the topology problem and introduces three new ones.

A single point of failure. Everything routes through the bus, so when the bus degrades, every integration degrades at once. In a tolling system where transactions must be captured in real time, a stalled bus means lost revenue, not a delayed report.

A bottleneck under volume. Heavy ESBs were designed for request-response orchestration, not sustained high-throughput streams. Push real transaction volume through synchronous bus mediation and latency climbs when you can least afford it.

A new monolith. Years of transformation rules, routing conditions and business logic accumulate inside the bus, until it is too central to remove and too fragile to change. The spaghetti moved inside the box.

An ESB is the right pattern when your integrations are orchestration-heavy and your volumes are moderate and predictable. It is the wrong pattern when you need to absorb bursty, high-volume, transaction-critical traffic, and many enterprises bought a heavy ESB for the second problem and got the first.

API-led integration: governing the contract, not the timing

API-led integration reframes the question. Instead of a central bus owning the flows, each system exposes well-defined APIs, often layered into system, process and experience tiers, and integration becomes a matter of consuming contracts.

This is a real improvement on the ESB for one reason: it governs the contract. A stable, versioned API means a consumer is no longer coupled to your internal schema, so you can change what sits behind it without breaking everyone downstream. Where many teams need self-service access to the same capabilities, this is the right backbone, and a modern enterprise integration platform is usually built around it.

But API-led integration has a blind spot that matters in transaction-critical contexts: APIs are synchronous by default. They govern the shape of the data, not the timing of the load. When a downstream system is slow or down, a synchronous call either blocks or fails. There is no buffer.

In billing, tolling and telecom, where a transaction spike is normal and dropping one is not acceptable, request-response APIs alone give you no backpressure. You need somewhere for events to wait when the consumer cannot keep up, and that somewhere is a queue or a log. API-led is necessary, but not sufficient on its own for these flows.

Event-driven and the event mesh: decoupling the timing

Event-driven architecture inverts the relationship. A producer emits an event and moves on, while consumers subscribe and process at their own pace. The two sides are decoupled in time, not just in schema. What this buys you under real transaction volume:

• Backpressure is built in. A durable log (Apache Kafka is the common choice) absorbs bursts. If a consumer falls behind, events wait in the log instead of being dropped or blocking the producer.
• Replay is possible. When a downstream billing process has a bug, you fix it and replay the events that a synchronous world would already have lost.
• Producers do not know their consumers. Add a fraud-detection, analytics or reconciliation consumer on the same stream without touching the producer.

An event mesh is the next step up: a distributed event-driven layer that routes events across regions, clouds and on-premise systems without point-to-point wiring between brokers. For cross-border tolling or multi-country telecom, where transactions originate in many jurisdictions and must reach many back-office systems, it is the pattern that fits the geography.

The tradeoff is honest: event-driven systems are harder to reason about. Eventual consistency, ordering guarantees and idempotent consumers are real engineering problems, not configuration switches. You adopt event-driven because synchronous patterns cannot give you backpressure and replay, and you need both.

Governance: the part that decides whether any of this lasts

The pattern matters less than the discipline around it. A clean event-driven backbone rots into a new tangle if nobody governs it, and a modest ESB runs reliably for a decade if someone owns the rules. What governance means concretely:

• A contract registry. Every event schema and API contract is versioned, discoverable and deprecated on notice. Breaking changes are not a surprise found in production.
• Clear ownership. Each flow, topic and API has a named owner responsible for its reliability and evolution. No orphaned integrations.
• Observability across the seams. You can trace a single transaction end to end, in a billing or tolling context where reconciliation is not negotiable.

The realistic path: strangle the worst links first

The instinct, once the tangle is undeniable, is a big-bang rewrite onto a clean event-driven backbone. In transaction-critical systems, big-bang rewrites are how you turn a maintenance problem into an outage.

The path that works is incremental. Inventory the point-to-point links and rank them by pain: volume, fragility, business criticality. Take the worst offender, the link that breaks most often or carries the most revenue, and route it through an event-driven layer first, old and new in parallel. Once the new path is proven, retire the old link, then take the next one.

This is the strangler pattern applied to integration. You never freeze the business for a rewrite, you shrink the tangle one link at a time, and at every step the landscape is more governed, not less. You reach an event-driven backbone with API-led contracts on top by subtraction.

Where DNA Solutions fits

We help European enterprises move from an accumulated tangle toward an integration architecture that holds up under real transaction volume, in billing, tolling and telecom contexts where dropping a transaction is not an option. That means mapping what you run today, choosing the right pattern per flow, and sequencing the migration so the business keeps running. If you are weighing an ESB, API-led integration or an event mesh against a point-to-point mess, talk to us.