Gateway zoo: API, Event, Kafka, and AI gateways through Conway's Law

The expansion of API Gateway to Event, Kafka, AI Gateways and its relation to Conway's Law.

Let's start with the famous statement of Conway's Law:

"Organizations that design systems are constrained to produce designs that are copies of their communication structures."

This perspective offers a critical key to understanding why API Gateway scope is constantly being extended with concepts like Event Gateway, Kafka Gateway, AI Gateway, Agent Gateway, and the like.

On one hand, this expansion risks turning API gateways into the bulky ESB (Enterprise Service Bus) structures of the past; on the other, we should not ignore scenarios where certain integrations can add value in line with technological evolution and pragmatic needs. Striking this balance sits at the center of modern architectural decisions.

A good starting point is the relationship between API Gateway and other specialized technologies. In the generally accepted approach, API Gateways handle "north–south" traffic (from external clients to internal services), while other platforms focus on different traffic patterns and integration needs. Using these technologies together — each specialized in its domain — yields a more scalable, manageable, and performant architecture for most large, complex systems.

However, especially in smaller projects with limited resources or low system complexity, or within the capabilities of certain platform products, combining functions in a single tool can be a pragmatic and reasonable solution.

Organizational structures and technological echoes

The link between organizational structures and technology choices is unavoidable. In setups where different teams build systems in their own silos and communication is strained, integration becomes a serious problem. API Gateways have gained popularity as a way to fill these organizational gaps and build bridges between silos.

ESBs, born of a similar need, can still be functional in certain enterprise integration scenarios, but they have often become bloated and an obstacle to change because of the claim to be the "one tool that solves everything." Whether API Gateways fall into the same trap depends largely on how organizations position these tools with awareness of Conway's Law, how clearly they draw responsibility boundaries, and whether they try to paper over fundamental organizational issues with technology.

Business logic creeping into the gateway

The question of business logic creeping into API Gateways calls for conscious judgment rather than rigid rules. Although this is often a symptom of organizational issues, it can sometimes offer pragmatic benefits:

• Data transformations. Simple formatting or field mapping in the gateway can be efficient. But transformations that involve complex business rules (e.g. detailed financial calculations) or change frequently are usually healthier in the application layer or a dedicated integration service.
• Authorization rules. Basic authentication and simple role checks (e.g. general endpoint access) can be managed centrally in the gateway. But resource-specific, business-rule-based, or highly detailed authorization logic is better owned by the relevant microservice or a dedicated authorization service.
• Event processing. Basic event filtering or simple routing may live in the gateway in some scenarios. For complex event correlation, anomaly detection, or stateful event-processing logic, dedicated event-processing platforms or messaging systems are better.

The key is not a dogmatic "never put business logic in the gateway" but a conscious evaluation of which part of the logic belongs in which layer.

From developer to specialized roles: opportunities and pitfalls

Software teams specializing around certain platform components (e.g. API Gateway) reflect the organization's capability management and technology strategy — and bring both opportunities and risks.

• Advantages. Fast value delivery, deep expertise in a specific area, full use of the platform's capabilities.
• Disadvantages. The team becoming dependent on a narrow technology or product (vendor lock-in risk), general software development skills eroding, reduced organizational flexibility to adapt to different solutions.

The ideal balance depends on the organization's size, strategic goals, resources, and culture. Large organizations may prefer deep specialization; smaller or more agile organizations may encourage T-shaped competencies with broader responsibility.

Balance between pragmatic solutions and ideal architectures

Real-world projects rarely proceed with purely "ideal" architectures. Often, pragmatic decisions are needed because of existing constraints, time pressure, and business needs:

• Pragmatic approaches. A bank temporarily adding "AI features" to its existing API Gateway to meet an urgent business need can be a reasonable step when resources are limited, market pressure is high, or the goal is to buy time until a more permanent solution is built. Such decisions can be seen as consciously taken and managed "technical debt."
• "Ideal" and long-term approaches. The same bank developing a purpose-built orchestration layer or a dedicated AI Gateway solution for AI services offers a more scalable, sustainable architecture. This lets each technology play to its strengths but requires more upfront investment and organizational coordination.

Successful organizations strike a conscious balance between these two approaches.

Technological evolution and decision factors

The spread of Event Gateway, Kafka Gateway, AI Gateway, and Agent Gateway shows that technology and business needs keep evolving and different communication patterns are emerging. Whether to address this new functionality inside existing API Gateways or to develop it as separate, specialized products is a strategic decision with no simple right / wrong answer; it depends on:

• Scale and complexity of the organization. Large, complex systems usually benefit from specialized components.
• Team structure and expertise. The capabilities and responsibility areas of existing teams.
• Nature and urgency of business needs. How complex the required functionality is and how quickly it must go live.
• Cost, resource constraints, and management overhead. Total cost of ownership of adding a new tool vs. extending the current one.
• Long-term strategic goals. Expectations for future flexibility and scalability.
• Capabilities of the current API Gateway. Modern API Gateway platforms can have more modular, plugin-based architectures than ESBs, which can make some integrations more manageable. But this modularity should not be a reason to put everything under one roof.

A balanced approach

Managing the effects of Conway's Law and building healthy technological architectures requires conscious steps on both the organizational and technological sides:

1. Set conscious, pragmatic boundaries. Clearly define the core responsibility areas of each technology — but draw these boundaries pragmatically, taking the project's and organization's context into account.
2. Align technology choices with business needs and organizational context. Base decisions not only on popular trends but on the ability to solve real business problems with your scale, resources, and teams.
3. Apply Conway's Law consciously. Aim for organizational structures that support your ideal architecture. But accept that organizational change takes time and that technological choices can sometimes trigger organizational evolution.
4. Focus on organizational improvement. Technology can be a tool to address organizational issues but is never the solution by itself.
5. Phased transition and manageable technical debt. The ideal architecture is rarely reached overnight. Develop phased transition strategies and manage the technical debt you take on consciously.

Conclusion

Whether concepts like Event Gateway, Kafka Gateway, and AI Gateway should be integrated into API Gateways or treated as separate products depends on the organization's context.

For large-scale, complex, long-lived systems, designing these functions as separate, specialized products or components with well-defined interfaces between them usually offers a more sustainable, scalable approach. This helps prevent API Gateways from sharing the fate of ESBs.

For smaller organizations, prototypes, situations with resource constraints, or specific, simple integration needs, pragmatically addressing some functions within the existing API Gateway platform may be more efficient.

What matters is making these decisions consciously — evaluating the factors carefully and weighing potential benefits and risks — rather than in haste or by assumption.

Learning from past ESB experience, we should keep API Gateways focused on their core value (API management, security, traffic control), make extension decisions in a measured way, and prefer specialized solutions for different needs, without ruling out pragmatic integration where it makes sense. In the end, the future of API Gateways will depend on how skillfully we manage this complex dance between technology and organization.