Understanding API Gateways: Kong Overview, Comparison, Features, Performance, and Deployment

1. What Is an API Gateway?

1.1 Origin

An API gateway acts as a crucial bridge between clients and services, consolidating cross‑cutting concerns such as authentication, rate limiting, circuit breaking, IP whitelisting/blacklisting, and monitoring.

1.2 Problems

When a monolithic service grows and is split into many micro‑services, each service would need to implement the same infrastructure logic, leading to duplicated effort and multiple domain names that increase client complexity.

1.3 Solution

The API gateway provides a unified entry point, routing all traffic to the appropriate micro‑service while centralising common functionalities, thereby presenting the micro‑services as a single logical service to the client.

1.4 Gateway Capabilities Summary

Reverse proxy / load balancing / health checks

Unified entry / security protection / traffic identification / traffic monitoring

Identity authentication

Rate limiting / circuit breaking

Canary release

Other common capabilities (e.g., Passport login verification)

2. API Gateway Comparison

We compare four mainstream gateways.

Name

Kong

Zuul

Spring Cloud Gateway

Tyk

Language

Lua

Java

Java

Go

High Concurrency

Based on OpenResty

Based on Netty async I/O

Based on Netty async I/O

Based on Go

Community Stars

30k

11.2k

3.1k

6.6k

Extensibility

Official plugins / custom plugins

Requires development

Filters

Plugins

Storage

Postgres, Cassandra, Yaml

In‑memory files

Code, Yaml, Config Center

Redis

Health Check

Supported

Supported

Supported

Supported

Authentication

Key, OAuth2.0, JWT, HMAC, Passport (custom)

Requires development

Basic auth, OAuth2.0

OAuth2.0, JWT, HMAC

Rate Limiting

Supported

Requires development

IP/User/Route based, extensible via interface

Supported

Monitoring

Datadog, Prometheus, Zipkin

Requires development

Gateway metrics filter

Tool suite

Lifecycle

Plugin development

Requires development

Register service to Eureka

Plugin development

Security

Bot detection, attack protection

Requires development

Requires development

Plugin support

Maintainability

Active community, plugin development, UI panel

Custom filter development

Spring Cloud ecosystem, limited resources

Less documentation, UI support

Note: Data sourced from the internet.

Conclusion

Our team has extensive experience with Nginx, so we prefer open‑source solutions built on OpenResty. Kong, written in Lua, inherits Nginx’s high‑concurrency strengths and enjoys a large community. We extended Kong to support MySQL clusters and built custom plugins for HMAC authentication, rate limiting, IP black‑/whitelisting, request transformation, and Prometheus metrics.

3. How Kong Works

Kong is built on OpenResty, which defines 11 execution phases. Kong injects its own logic into these phases, as shown in the Nginx configuration snippets below.

Execution Phases (simplified)

kong.init : load configuration, initialise routes.

kong.init_worker : load global events.

kong.rewrite & kong.access : authentication, request validation, rate limiting, header manipulation.

kong.header_filter & kong.body_filter : final request/response filtering.

kong.log : monitoring after response is sent.

4. Kong Features

4.1 Cluster Scalability

Kong supports four cluster modes: Yaml configuration, Postgres, Cassandra, and a custom MySQL mode (officially unsupported). The cluster synchronises routing information via a 1‑second polling of a cluster_event table.

4.2 Plugin Architecture

All non‑routing functions (auth, rate limiting, monitoring, etc.) are implemented as plugins. We have developed custom plugins for HMAC auth, rate limiting, IP black‑/whitelisting, request transformation, and Prometheus metrics, as well as higher‑level plugins like Passport and Auth to simplify business‑side code.

4.3 Multi‑Platform Support

Kong runs on CentOS and can be deployed in Docker or Kubernetes environments.

5. Kong Performance

Kong inherits Nginx’s asynchronous, non‑blocking architecture, providing high concurrency. Two cache layers (per‑worker LRU and shared shared_dict ) reduce database load. The following benchmark compares raw service access, plain Nginx proxy, and Kong with different storage back‑ends (all plugins disabled).

Scenario

Avg (ms)

TP90 (ms)

TP99 (ms)

RPS

Direct service access

1.28

1.49

2.60

78,554

Pure Nginx proxy

1.49

1.72

2.95

67,618

Kong + Yaml

1.69

2.17

4.05

59,823

Kong + MySQL (custom)

1.77

2.37

4.30

56,816

All results satisfy our business requirements.

6. Kong in Our Architecture

We place Kong between the cloud provider’s Layer‑4 load balancer and our internal Layer‑7 SLB. Kong provides a unified, secure entry point for internal services.

By configuring plugins via files or databases, we can quickly add or remove capabilities.

7. Monitoring Kong

We built a Grafana dashboard backed by Prometheus, exposing Nginx shared‑memory metrics, connection stats, RPS, bandwidth, and latency.

8. Issues Encountered and Solutions

8.1 MySQL Cluster Support

Because we did not want to introduce Postgres or Cassandra, we added custom MySQL support for Kong clustering.

8.2 Management UI

Kong Enterprise’s UI is costly; open‑source dashboards (Kong‑Dashboard, Konga) have compatibility or permission‑granularity issues, so we are building a simplified internal UI.

8.3 Upstream Prematurely Closed Connection

The error stemmed from mismatched idle‑timeout settings (Java service 30 s vs. Nginx 60 s). Reducing Nginx’s timeout to 25 s eliminated the issue.

8.4 Real IP Retrieval in IP‑Restriction Plugin

We modified the plugin to check X-Real-Ip , x_forwarded_for , and remote_addr headers in order, enabling correct client IP detection.

8.5 Prometheus Plugin Performance

Version 0.6 caused high latency; after benchmarking, we upgraded to 0.9, which reduced average latency from 6.68 ms to 1.76 ms and increased throughput.

9. Final Thoughts

API gateways have been successfully deployed across many of our business lines, meeting most requirements. Kong’s extensibility allows us to supplement core functionality with custom plugins, and its active community provides valuable resources. We plan to continue contributing back to the open‑source ecosystem.

END