"Organizations that design systems are constrained to produce designs that copy the communication structures of those organizations."
Conway's law is one of those quotes everybody nods at and then ignores for the rest of the meeting. It deserves better attention right now, because it explains something that's happening across the API platform space — the steady expansion of "API gateway" to include Event gateway, Kafka gateway, AI gateway, agent gateway, and whatever the next noun turns out to be.
This expansion is both real and risky. The pragmatic value is genuine — some integrations belong together. The risk is that API gateways quietly turn into the next-generation Enterprise Service Bus and inherit every problem ESBs had. Navigating the middle requires deliberate choices, not defaults.
Where the pressure comes from
Conway's law is usually invoked in reverse — "if your architecture looks like X, your organization probably looks like X." That's the diagnostic version. The forward version is the one operating right now: "if your organization looks like X, you will keep building tools that look like X, whether you mean to or not."
Most enterprises today have silos. They have a payments team, a customer-data team, a fraud team, a mobile team, an integrations team, and an AI team — each with its own backlog, its own vendor stack, and its own definition of "done." API gateways exist in large part to bridge those silos. They became the obvious place to put cross-cutting concerns because they are the place every silo's traffic already passes through.
That's exactly how ESBs got their start — born for the same reason, solving the same problem. The ESB story didn't end well for most teams that lived through it. The lesson isn't "never put anything in the gateway." It's "be very deliberate about what goes in and why."
Business logic in the gateway — when it's fine, when it isn't
Engineering blogs love to declare absolutes: "no business logic in the gateway, ever." Real systems are messier. A useful heuristic is to ask, for any piece of logic that wants to live in the gateway, whether it changes per-business-process or stays per-platform.
Data transformations. Simple format mapping or field projection at the gateway is often fine — and faster than asking every service to re-implement the same transform. Complex business-rule transformations, or transformations that change frequently with business processes, belong upstream of the gateway in an integration service.
Authorization. Coarse-grained authentication (is this caller identified? does it have a valid token?) is the gateway's job. Resource- specific authorization ("can this caller see this customer?") belongs in the service that owns the data — the service has the context the gateway doesn't.
Event processing. Lightweight filtering or routing on event streams can sit at the gateway. Stateful event correlation, anomaly detection, or business-level CEP belongs on a specialized event platform — that's what those platforms are built for.
The same pattern applies to every new "gateway" category. The question is always: does this responsibility change for platform reasons, or for business reasons? Platform-reason changes belong on the platform. Business-reason changes belong in the services that own the business process.
The specialization trade-off
When a platform centralizes a function, the org centralizes around it. Teams form around "the gateway platform," and over time those teams develop deep expertise — and a vendor dependency. That trade is real.
The advantages are real. Faster value delivery. Deep platform expertise. Maximum utilization of platform capabilities. Better audit, better security, fewer reinventions.
The risks are also real. Vendor lock-in. Atrophied general engineering skills outside the platform's idioms. Reduced organizational flexibility when a strategic direction changes.
The right balance depends on organization size, strategic goals, budget, and culture. Large enterprises with steady strategy can absorb specialized roles. Smaller, faster organizations are usually better served by T-shaped engineers who can dip into the gateway when they need to and live in services the rest of the time.
Pragmatism beats purity in real timelines
In a textbook, you'd always build dedicated platforms for each new traffic shape — a dedicated AI gateway, a dedicated event gateway, a dedicated agent gateway. In practice, real projects have real timelines and real budgets.
Quick fix. A bank adds basic AI traffic governance to its existing API gateway because it has a regulatory deadline and one quarter to land it. That's "managed technical debt" — fine for what it is, as long as the team knows it's debt and has a plan to pay it down.
Ideal architecture. The same bank, twelve months later, has the budget and the runway to stand up a dedicated AI gateway as a peer to the API gateway, sharing the same identity, audit, and observability plane. That's the destination. It costs more up front. It pays back over the next three years.
Successful organizations don't insist on either extreme. They make deliberate trade-offs, label the technical debt clearly, and pay it down on a schedule.
What drives the per-category decision
Whether Event, Kafka, AI, and Agent gateways become features of an existing API gateway or stand up as separate products depends on a few concrete factors:
- Scale and complexity. Large, complex, long-lived systems benefit from specialized components with clear interfaces.
- Team structure and expertise. What does your team know? What can it operate? What can it hire for?
- Business needs. How complex are the requirements? How fast does the rollout need to happen?
- Total cost of ownership. Operating two platforms costs more than operating one. Operating an overgrown platform costs more than operating one well-scoped one.
- Long-term vision. Where is the architecture going? Will today's consolidation get in the way of tomorrow's flexibility?
- Current platform capability. Modern platforms offer modular architectures that make selective addition easier — that's a real factor, but it shouldn't become a reason to consolidate everything by default.
Five principles that keep the gateway useful
The teams we've seen avoid the ESB trap follow most of these:
- Define boundaries deliberately. What's in the gateway? What's not? Why? Write it down. Revisit it once a year.
- Match technology to business needs. Pick tools because they solve real problems, not because they're trending.
- Apply Conway's law on purpose. Design the org you want, then let the architecture follow. Don't accept the architecture that the accidental org structure produces.
- Fix the organizational problem first. Communication gaps, unclear ownership, and silos cause most "let the gateway handle it" pressure. Address the cause, not the symptom.
- Stage transitions and manage debt explicitly. Ideal architectures don't ship overnight. Build a phased plan, derive value at each phase, and pay down technical debt with a schedule instead of a hope.
Where this leaves API gateways
For large-scale, complex, long-lived systems, the right answer is usually specialized, well-scoped components with clear interfaces — including a dedicated API gateway, a dedicated AI gateway, and dedicated event infrastructure. That's how API gateways avoid the ESB fate.
For smaller organizations, prototypes, resource-constrained teams, or genuinely simple integration needs, folding some of these functions into a capable API gateway platform is often more efficient than operating multiple platforms.
The mistake on both sides is reflexive. Reflexively consolidating because "modular platform" looks good in a sales deck is a fast path to an unmaintainable platform. Reflexively splitting because "purity" is a fast path to platform sprawl.
Make the decision deliberately. Look at the factors. Weigh them. Pick a direction. Revisit it next year.
If you want to talk through where the AI gateway and event gateway sit relative to your existing API gateway, we've had this conversation with banks, ministries, and telcos in the last twelve months — happy to share what we've seen.