Why ‘API Gateway’ is Not an Integration Style
Even in its New Event-Driven Clothes
In conversations with prospects and customers one statement comes up again and again: “Our integration style? API Gateway.” At first this sounds reasonable. Most organisations today have an API gateway in place and many have built significant parts of their system landscape around it. Recently the same claim has started to appear in a new flavour: “We are using an event gateway, so we have solved event-driven integration.”
What is striking here is not the presence of gateways. They are valuable and in many cases indispensable. What is striking is the way the label “integration style” gets attached to them, as if a single product or component could define the architectural approach of an entire organisation. The API gateway is turned into shorthand for an integration strategy, while the event gateway is marketed as the central nervous system of modern event-driven enterprises.
This way of thinking is tempting. Gateways feel tangible. They provide a single pane of glass, dashboards, policy engines and vendor roadmaps. They are easy to point to and declare: “This is how we integrate.” And that is where the problem begins. When a gateway, whether API or event-based, is mistaken for an integration style, organisations fall into the trap of believing that infrastructure defines architecture. Even worse, they begin treating the gateway as the lifeguard of their entire API initiative, the single thing that will keep everything else safe.
No gateway, however advanced, can rescue a struggling API strategy. Gateways enforce, route and standardise, but they do not design, govern or align APIs with business value. Confusing a runtime facade with an architectural style creates false expectations and fragile foundations. To understand why this matters, we need to revisit what integration styles really are.
What Integration Styles Really Are
When people claim that an API gateway, or its newer event-driven sibling, is their integration style, they are collapsing two very different concepts. Integration styles describe the fundamental ways in which systems exchange information and coordinate work. The idea goes back decades and was laid out systematically in Gregor Hohpe and Bobby Woolf’s Enterprise Integration Patterns.
Styles are not tied to a specific vendor product or runtime box. They capture how systems interact at a conceptual level. The most common are request and response, publish and subscribe, event streaming, and batch or data replication. Each comes with its own trade-offs in timeliness, coupling, scalability and complexity. No single style is universally better. In practice organisations need a portfolio of them, applied where they make the most sense.
Beneath these architectural styles sit the interaction patterns that shape how consumers and providers experience an API or event stream. Mehdi Medjaoui, Erik Wilde, Ronnie Mitra and Mike Amundsen, as authors of the book "Continuous API Management, 2nd Edition", have defined these as four basic patterns: resource or hypermedia, query, tunnel, and event-based. A resource pattern exposes navigable entities. A query pattern allows consumers to ask questions flexibly against a dataset. A tunnel pattern sends opaque payloads to be processed without exposing structure. An event-based pattern emits and reacts to state changes. These patterns operationalise a style by turning it into something that developers can implement and consumers can use.
Confusing style, pattern and component is not new. In the early 2000s many organisations equated the Enterprise Service Bus with the hub-and-spoke style of integration. Vendors encouraged this, selling ESBs as complete strategies rather than as tools. InfoQ later captured the disappointment in its piece The Rise and Fall of the Internet Service Bus. The result was brittle architectures and over-centralised governance. Fast forward to today and the same mistake repeats itself. Instead of the ESB we now hear “Our integration style is the API Gateway” or “We are using an event gateway, so we are event-driven.” In both cases the error is the same: mistaking a runtime enforcement point for the deeper architectural decisions that actually shape system-to-system interaction.
Integration styles endure because they describe what kind of interactions we rely on. Interaction patterns make those interactions tangible for consumers. Runtime components such as gateways, brokers or meshes enable those choices but do not define them. When we conflate these levels we set ourselves up for the same disappointments that followed the ESB era.
From HTTP to Events – The New Gateway Flavour
For years the API gateway was the poster child of API enablement. It routed requests, enforced policies, translated protocols and gave architects the comfort of a single point of control. Recently a new flavour entered the stage: the event gateway. It promises to do for asynchronous flows what the API gateway did for HTTP, to become the beating heart of integration, the place where everything is visible, controlled and secured.
The promise is attractive. Event gateways can route and filter events between producers and consumers, enforce policies and quotas on topics and streams, translate protocols such as MQTT or AMQP into Kafka or CloudEvents, and provide observability into event-driven landscapes. The sales story is familiar: wrap the messy details behind a facade and it looks as if integration has been solved. Just as before, teams are tempted to declare: “We have an event gateway, so we are event-driven.”
This is dangerous. An event gateway does not make an organisation event-driven, just as an API gateway never made anyone API-first. Ben Stopford in Designing Event-Driven Systems points out that the hard work lies in event modelling, schema evolution, and consumer enablement. An event gateway cannot answer these questions. It is only a control point, a useful one, but still just a runtime enforcement layer.
We have seen this movie before. In the ESB era enterprises believed that buying an ESB meant adopting hub-and-spoke integration. The result was brittle architectures and disappointment. Today the same mistake resurfaces with new marketing slogans. No gateway will ever be the lifeguard of an API or event initiative. Gateways enforce, route and observe. They do not rescue poor design, unclear models, lack of ownership or weak governance. Treating them as a strategy is like mistaking the facade of a building for its foundations. It looks neat but collapses under stress.
Event gateways, like API gateways, do have their place. They can accelerate, they can provide guardrails, and they can make distributed integration more manageable. But they are never the centrepiece of an integration style. If you rely on them to save your initiative you are repeating the same false expectations that the ESB era left behind.
The Facade Pattern – Helpful, But Not the Whole
One concept explains both the strength and the limitation of gateways: the Facade pattern. Introduced in the Gang of Four’s Design Patterns, a facade provides a unified interface to a set of interfaces. Its purpose is not to add new functionality but to simplify, standardise and hide complexity.
This is exactly what gateways do. An API gateway simplifies HTTP traffic, and an event gateway does the same for asynchronous flows. They provide one entry point instead of many, enforce consistent security, and offer monitoring and throttling. They make a messy world appear neat. Chris Richardson described this clearly in his well-known API Gateway pattern for microservices: a single entry point that handles cross-cutting concerns such as authentication, routing, monitoring, and protocol translation. In other words, it is a classic facade.
This comparison is valuable, but only if we keep the role of the facade in perspective. A facade is never the system itself; it is the front door. The real work happens behind it in the services, APIs or event streams. If these are poorly designed, badly governed or misaligned with business needs, the facade cannot compensate. It simply exposes the weaknesses more uniformly.
Thinking of a gateway as an integration style is therefore misleading. By definition a facade cannot dictate the architecture of what lies behind it. Declaring that your integration style is API Gateway or Event Gateway is like saying the design of your house is the front door. The door may be elegant and secure but it says nothing about whether the rooms behind it are usable or even connected to one another.
There is also the danger of a false sense of control. With dashboards, centralised policies and neat metrics, it can look as if integration is solved. But in reality what you control is only the entry point, not the quality, consistency or purpose of the APIs and events themselves. This illusion is precisely what led ESB programmes to fail: centralised control without distributed responsibility.
Seen this way, gateways are useful but strategically limited. They are helpers, not leaders. They enforce, expose and simplify, but they do not define styles, create consumer value or rescue initiatives without strategy.
Why the Confusion Happens
If gateways are only facades, why do so many organisations treat them as if they were integration styles?
Vendor marketing has blurred the lines. The gateway market exploded with the rise of REST, and vendors sold gateways not just as tools but as strategies. Today the same playbook is applied to event gateways, wrapped in the language of Gartner’s “event-driven IT” trend reports.
The shadow of the ESB still looms large. After many organisations were burned by heavy ESB rollouts, the API gateway became the lightweight alternative, a way to say “we are integrating” without admitting that the underlying mindset remained the same.
Gateways also provide visible and tangible value. They come with consoles, roadmaps and diagrams. They are easy to point to. For executives it is simpler to declare “this box is our strategy” than to engage in a conversation about the trade-offs between request and response, event-driven or batch.
Finally, language adds to the confusion. Architects talk in terms of integration styles and patterns. Product teams and platform owners talk in terms of components and tools. When these conversations overlap, “style” becomes a catch-all for “how we connect things,” and the gateway ends up wearing the label because it is the most visible part of the setup.
Together these factors create a powerful illusion: that the gateway is the integration style, maybe even the integration strategy. But illusions come at a cost. They foster over-reliance, distract from deeper questions, and set up organisations for disappointment when the gateway inevitably fails to deliver on promises it was never designed to keep.
Federated API Management – The Counter-Model
The antidote is to place gateways back where they belong: as enablers inside a broader federated API management model.
In a federated approach, management is not concentrated in a single team or box. Responsibility for exposing and governing APIs is distributed across domains, while common policies and standards are enforced consistently through tooling.
Gateways still matter here. In the synchronous world, an API gateway handles authentication, routing and monitoring. In the asynchronous world, an event gateway may filter events, apply access policies and route traffic into event backbones. But in this model the gateway is never the style and never the strategy. It is an infrastructure facade that supports teams, not a lifeguard that saves them.
Federation reflects reality. No modern enterprise relies on just one integration style. They need synchronous APIs for partners, event-driven integration for responsiveness, and batch processes for legacy systems. A federated model allows these to co-exist, with gateways acting as enforcement points but never as substitutes for strategy.
API Thinking – Strategy Before Tooling
Federation answers who owns what. API Thinking answers why an API or event exists at all.
API Thinking starts with the value proposition. What problem does the API or event solve for its consumer? Once that is clear the right interaction pattern can be chosen. If consumers need navigable entities the resource pattern is appropriate. If they need flexible access to data, query is the right fit. If the need is to pass commands, tunneling works. If reacting to state changes is valuable, event-based is the right choice.
Only after the interaction pattern comes the integration style, whether synchronous request and response, publish and subscribe, event streaming or batch. And only then comes the runtime component, whether a gateway, broker, mesh or pipeline.
Too often organisations invert this sequence. They start with the tool they have bought and retrofit strategy and design decisions around it. The result is predictable: APIs that exist because the gateway is there, not because a consumer needs them. Event streams routed because a gateway can handle them, not because anyone asked for the value they deliver.
Kin Lane has recently written about the importance of first party APIs as part of this thinking. Mike Amundsen has argued that starting with value is what makes ecosystems sustainable. Both voices point to the same principle: strategy before tooling.
API Thinking ensures that gateways are used as enablers rather than definitions. It reminds us that no gateway, whether API or event-based, will ever be the lifeguard of an initiative. The lifeguards are ownership, governance and consumer alignment.
The Risks of Gateway-as-Saviour Thinking
The temptation to see gateways as the centrepiece of an initiative is understandable, but it is dangerous. Treating an API or event gateway as the saviour of integration creates false security, architectural blind spots, over-centralisation, misaligned investments and failed programmes.
Erik Wilde and colleagues in Continuous API Management again explain that governance, design and lifecycle alignment are what sustain APIs. Gateways provide guardrails, but without design and ownership they only enforce surface-level rules.
Believing governance is “handled” at the gateway covers only the surface. A gateway-centric mindset narrows integration to whatever the gateway can expose, sidelining other necessary approaches. Over time the gateway becomes a bottleneck, replaying the same centralisation issues as the ESB era. Investment becomes skewed toward infrastructure while design and enablement are neglected. And at the extreme, initiatives fail outright because poorly designed APIs or badly modelled events are not adopted, no matter how neatly they are routed or monitored.
Gateways are valuable, but only as facades and enforcers. They cannot carry the strategic weight of defining styles, guiding design or ensuring adoption. Expecting them to do so simply repeats old mistakes under new branding.
A Healthy Architectural View
A healthy architecture starts by restoring the right order. Integration styles set the foundation. Interaction patterns make them tangible. Runtime components enforce and enable. Gateways sit firmly in this last category. They are facades that protect and expose, not the architectural backbone.
Federated API management ties everything together by distributing responsibility across domains while keeping governance consistent. In this view APIs and events emerge from domains with clear value propositions, shaped by patterns and exposed through infrastructure that provides guardrails. The gateway is present but plays a supporting role.
This produces resilience and adaptability. Organisations can evolve styles, combine synchronous and asynchronous, and integrate legacy without being trapped by a single product. Governance scales without bottlenecks because ownership is federated. Most importantly, integration remains aligned with business value rather than vendor dashboards.
Closing – No Lifeguard on Duty
The temptation to declare “Our integration style is the API Gateway” or “We are event-driven because we have an event gateway” will persist. It is easy to do because gateways are visible and tangible. They provide dashboards that executives can point to and say, “We are integrating.”
But gateways are facades. They enforce and expose; they do not define or rescue. Mistaking them for an integration style is not just a semantic slip — it is a strategic risk. It leads to false security, architectural blind spots, over-centralisation, misaligned investments and ultimately failed API initiatives.
A healthier approach is to put styles and patterns first, let runtime components serve them, and distribute responsibility through federation. Strategy comes before tooling. API Thinking before dashboards. Ownership before facades.
And it is worth underlining one final point. Even in Chris Richardson’s original description of the API Gateway pattern for microservices, the gateway was never framed as a style or a strategy. It was described as a deployment pattern, a single entry point that simplifies access and manages cross-cutting concerns. That is all it ever was: a facade, not an architecture.
The conclusion is clear. No gateway, API or event-based, will ever be the lifeguard of your API initiative. Lifeguards rescue. Gateways do not. What rescues an initiative is strategy, ownership, good design and strong governance. Gateways are essential helpers, but they cannot do the swimming for you.