Historical context: this article was originally published in April 2015, when Mashape released Kong as an open-source API management layer. Kong has since developed into Kong Gateway and a broader API platform. The original launch context is preserved below, while current capabilities and deployment guidance are linked to the official Kong documentation.
What Kong introduced in 2015
Kong was introduced as an extensible gateway that could sit in front of APIs and centralize cross-cutting concerns. Instead of implementing authentication, traffic limits, logging, and request transformation separately in every service, teams could apply those controls at a shared proxy layer.
The plugin model was central to the product's appeal. It allowed API operators to add policies and integrations around proxied traffic while keeping application services focused on their own business logic. This gateway pattern became especially relevant as teams adopted more services and needed consistent runtime controls.
What remains accurate today
Kong's current documentation still describes Kong Gateway as a reverse proxy that manages, configures, and routes API requests. Plugins and policies can address authentication, traffic control, observability, and transformations.
The architectural value is also unchanged: common API behavior can be applied at the gateway rather than duplicated across every upstream service. The gateway does not replace secure backend authorization, API design, or integration logic; it controls and observes traffic reaching those systems.
What changed since the original article
The 2015 description should not be used as current deployment documentation. Modern Kong Gateway supports several deployment topologies, and the old assumption that every installation relies on the same NGINX-and-Cassandra architecture is no longer correct.
- Traditional mode uses gateway nodes connected to a shared database.
- Hybrid mode separates control-plane configuration from data-plane traffic processing.
- DB-less mode loads declarative configuration without a central database.
The official deployment-topology guide explains current benefits and limitations. Product editions, plugin compatibility, configuration methods, and licensing should be checked in current Kong documentation rather than inferred from this historical launch article.
Kong Gateway versus API integration
An API gateway manages traffic between clients and backend APIs. API integration connects systems and maps their data or workflows. These capabilities are complementary but not interchangeable.
For example, a SaaS company may use Kong Gateway to protect and observe its public API while using API2Cart to connect its backend with 70+ commerce platforms. Kong governs access to the company's API; API2Cart reduces separate shopping-platform connector work.
How to evaluate Kong today
Start with current traffic, deployment, security, observability, plugin, and operational requirements. Compare self-managed and managed options, confirm plugin compatibility with the selected topology, and test configuration rollout and gateway failure behavior. The historical significance of the 2015 release is useful context, but production decisions should rely on supported versions and current official documentation.
Marketing manager, API fan, nerd, perfectionist, British humour enthusiast, literature and history geek.
