Understanding the Role and Selection of API Gateways in Enterprise Architecture

In this article we explore the purpose and functions of API gateways in modern enterprise architectures.

1. Uses of API Gateways

API gateways are applied in three typical scenarios.

Open API : Enterprises expose data and capabilities as a development platform (e.g., Taobao Open Platform, Tencent QQ Open Platform, WeChat Open Platform). An Open API platform requires unified entry for partner application onboarding, permission management, and call‑rate control, which is precisely the role of an API gateway.

Micro‑service gateway : Since the concept of micro‑services was popularized by Martin Fowler in 2012 and gained momentum after 2014, a micro‑service gateway becomes essential for handling load balancing, caching, routing, access control, service proxy, monitoring and logging. In a micro‑service architecture the API gateway acts as the micro‑service gateway.

API service management platform : For enterprises that cannot fully adopt micro‑services due to legacy systems, many internal APIs still need to be managed, monitored and visualized. An API gateway can serve as an API service management platform, providing visibility and control over inter‑system calls.

2. Position of API Gateways in the Overall Architecture

As system complexity grows, enterprises typically have external partner applications, public‑facing applications, and internal intranet applications. These three categories should be isolated with separate gateways: one for Open API partners, one for internal applications, and one for internal public‑facing applications.

3. How Enterprises Apply API Gateways

1) Open API gateways require partner applications to register on the Open API platform; a partner‑facing portal is needed to let partners obtain credentials.

2) Internal API gateways act as a micro‑service gateway or an API governance platform, managing REST‑style service calls between systems.

3) For internal public‑facing applications (e.g., mobile apps, corporate websites) a dedicated gateway can isolate business priorities and allow independent scaling.

Separate gateways isolate partner traffic from core business traffic.

Management processes differ between internal and partner APIs.

Internal APIs often have higher functional extension requirements than Open APIs.

When possible, it is advisable to use distinct gateways for partner Open APIs and internal public‑facing applications.

4. Competing Solutions for API Gateways

For Open API platforms the API gateway itself is the primary solution; no comparable alternatives were found.

For micro‑service gateways there are many options, including Service Mesh (e.g., Istio) which eliminates the need for a traditional gateway by using sidecar proxies.

Dubbo‑based architectures often bypass a gateway entirely, relying on a registry to direct clients to service providers.

5. API Gateway Solutions

Private‑cloud open‑source solutions :

Kong – built on Nginx + Lua (https://konghq.com/)

Netflix Zuul – Spring Cloud component (https://github.com/Netflix/zuul)

Orange – Chinese open‑source project (http://orange.sumory.com/)

Public‑cloud solutions :

Amazon API Gateway (https://aws.amazon.com/cn/api-gateway/)

Alibaba Cloud API Gateway (https://www.aliyun.com/product/apigateway/)

Tencent Cloud API Gateway (https://cloud.tencent.com/product/apigateway)

Self‑developed solutions :

Based on Nginx + Lua + OpenResty (the foundation of Kong and Orange)

Based on Netty, non‑blocking I/O (used by companies such as Yirendai)

Based on Node.js, leveraging its inherent non‑blocking nature

Based on Java Servlet (e.g., Zuul), though performance may be limited

6. How Enterprises Should Choose an API Gateway

When selecting an existing gateway, consider the following aspects:

1) Performance and Availability : The gateway becomes a core component, so latency should be under 10 ms and it must support non‑blocking I/O, clustering, and fault‑tolerant deployment.

2) Extensibility and Maintainability : Evaluate the effort required for customization and ongoing maintenance.

3) Requirement Fit : Ensure the gateway satisfies specific needs such as partner onboarding, quota management, micro‑service monitoring, etc.

4) Open‑source vs. Proprietary : Open‑source options (Kong, Zuul, Orange) provide source code but may lack UI, monitoring, or enterprise‑grade features; a strong internal development team is required for successful adoption.

5) Cloud Deployment Model : Public‑cloud gateways are convenient but may not meet strict security or customization requirements; private‑cloud or self‑hosted gateways are often preferred for enterprises with stringent compliance needs.

In summary, while public‑cloud gateways satisfy simple use‑cases, most enterprises with complex or security‑sensitive environments should opt for a private‑cloud or self‑developed API gateway solution.