Architecture

Integration architecture: API gateway, ESB, and event bus in a modern enterprise

The integration layer is the foundation of any digital transformation. Without it, every new application builds integrations from scratch, total cost of ownership grows non-linearly, and changes in one system break five others. This article covers three integration models — API gateway, ESB, event bus — and how to combine them in a mature landscape.

Discuss Your Challenge

This architectural article covers three integration layer models — API gateway, ESB, event bus — and the approach to combining them in a mature enterprise landscape.

What architecture challenge is being solved

Most regional enterprises have dozens of systems accumulated over 10-20 years. Each system is integrated with adjacent ones point-to-point — synchronous API, file, direct database access. After several years, a dependency web forms that no one fully maps. Every new requirement touches 5-10 systems; changes become slow and dangerous. The integration layer is not a single product but an architectural decision uniting API gateway, ESB, and event bus depending on interaction nature.

Which systems, data flows and teams are involved

API gateway — single entry point for synchronous requests, access control, rate limiting, API versioning
ESB (Enterprise Service Bus) — orchestration of complex inter-system processes, format transformation, delivery guarantee
Event bus — asynchronous event bus for reactive integration (Kafka, RabbitMQ, AWS Kinesis)
Service and API catalog — discovery, documentation, usage monitoring
Security layer — OAuth, mTLS, audit log, contract control
Observability — distributed tracing, metrics, logging across all systems

Typical architecture mistakes

Using API gateway as a universal solution including for asynchronous and long-running processes — violates architectural intent
ESB as a logic dumpster — all rules and transformations baked into the bus, business logic disappears
Event bus without schemas and contracts — events of arbitrary format are published, consumers break on every change
No API catalog — developers do not know what already exists, duplicate functionality
Synchronous inter-service calls through event bus — latency grows, one service failure cascades
No API versioning — a change breaks all existing consumers

Possible approaches

API gateway for synchronous business APIs — for channels and partners. With access control, limits, versioning.
Event bus for asynchronous interactions — all domain events published as facts, consumers react in their own pace
ESB for orchestration of complex multi-step processes — where execution guarantee and compensation on failure matter
Schema registry for compatibility control of events and APIs — mandatory part of a mature landscape
Service and contract catalog — single source of truth for all dev teams

How to avoid unnecessary core replacement

The integration layer is built around existing systems, not in their place. Old systems remain sources of truth in their domains — the layer adds asynchronous event flows and APIs for channels. Functionality is gradually moved out of old systems as they age, but this is not a precondition for building the layer; it is the natural continuation 2-3 years later.

Risks, dependencies, constraints

Dependency on data quality at sources — the layer will not fix garbage data in the core
Bus performance under volume growth — requires capacity and observability
Distributed process debugging complexity — distributed tracing is mandatory
Operations team maturity — without on-call for the bus and observability, the integration layer becomes a bottleneck
Security of every channel and every API — separate work, not an add-on

How a phased roadmap should look

Months 1-3: design target integration architecture, technology selection, integration team formation
Months 4-9: deploy API gateway for channels and partners, baseline event bus, observability
Months 10-15: migrate the first 5-10 key integrations to the new layer, retire point integrations as ready
Months 16-24: ESB for complex processes, schema registry, service catalog
After 24 months — gradual expansion, planned migration of remaining point integrations by priority

→

What else is worth exploring

Topics from the same area we usually explore together

Solution

These are not just articles

I do not just write about this. I can come in, examine your situation and design a solution for your specific landscape.

Discuss applying this →

← Back

Ready to discuss your challenge?

Tell me what's not working or what needs to be built. First conversation — no obligations.

Discuss Your Challenge Write on Telegram

Usually respond within a few hours