Understanding the Role and Selection of API Gateways in Enterprise Architecture

In this article we explore the functions of API gateways, covering three main scenarios: Open API platforms that expose corporate data and capabilities to external developers; microservice gateways that handle load balancing, caching, routing, access control, service proxy, monitoring, and logging within a microservice architecture; and API service management platforms that provide visibility and governance for legacy or heterogeneous systems.

Within an enterprise, different types of applications—external partner apps, public-facing services, and internal intranet apps—should be managed by separate gateways: an Open API gateway for partner integrations, an internal gateway for intranet services, and a public‑facing gateway for company‑owned web or mobile applications.

When applying API gateways, the article outlines specific practices: partners register applications on an Open API portal; internal gateways act as microservice gateways or API governance platforms; and public‑facing gateways can be dedicated or shared with partner gateways, offering benefits such as isolation of business impact, distinct management processes, and greater extensibility for internal APIs.

Competitive solutions are discussed, including the lack of alternatives for Open API gateways, the variety of options for microservice gateways (including Service Mesh solutions like Istio), and the fact that some Dubbo‑based architectures bypass gateways entirely.

Recommended API gateway solutions are categorized as:

Private‑cloud open‑source options: Kong (Nginx+Lua), Netflix Zuul (Spring Cloud), and Orange (a Chinese open‑source project).

Public‑cloud offerings: Amazon API Gateway, Alibaba Cloud API Gateway, and Tencent Cloud API Gateway.

Self‑developed approaches: Nginx+Lua+OpenResty, Netty‑based non‑blocking I/O, Node.js‑based implementations, and Java Servlet‑based solutions (e.g., Zuul).

Guidelines for selecting an API gateway focus on five key aspects:

Performance and availability – low latency (ideally <10 ms), non‑blocking I/O, clustering, and unified monitoring.

Scalability and maintainability – ease of extension and hand‑over to internal teams.

Requirement fit – matching core needs such as partner onboarding, rate limiting, or microservice observability.

Open‑source vs. commercial – evaluating the maturity, community support, and internal development capability for projects like Kong, Zuul, or Orange.

Deployment model – deciding between public‑cloud gateways (quick to adopt but limited in customization) and private‑cloud/self‑hosted gateways (necessary for strict security or advanced internal requirements).

Overall, the analysis concludes that while public‑cloud gateways suffice for simple use‑cases, most enterprises with complex integration, security, or performance demands should adopt private‑cloud or self‑built API gateway solutions.