Kong as an API Gateway: Centralizing Microservice Traffic with Konga and Flask

Introduction

As applications move from monoliths to microservices, every new service tends to expose its own API. That sounds fine at first—until each service also has to handle its own authentication, rate limiting, logging, and routing. The result is duplicated logic scattered across every service, and clients that need to know about every backend individually.

In one of our MSP infrastructure projects, we set up Kong as a centralized API Gateway in front of a set of backend microservices, using Konga as the visual admin layer and a Flask application standing in for a real backend service. The objective was to give every client request a single, secure entry point instead of scattering authentication, rate limiting, and logging across services.

In this blog, we will cover:

What an API Gateway is and why it is needed
How an API Gateway differs from a load balancer
The Flask–Kong–Konga architecture
Implementation steps
Rate limiting and authentication plugins
Best practices for running Kong in production

What Is an API Gateway?

An API Gateway is the entry point that acts as a bridge between clients and backend services. In a microservices architecture, it is the single door through which all client requests pass, giving teams consistent access control, security, and performance across many independent APIs.

What it does:

Routes and controls incoming API requests
Manages authentication, rate limiting, and caching
Provides centralized logging and monitoring
Enables versioning, transformation, and security policies
Improves performance and simplifies client interaction

Why Do We Need an API Gateway?

Without a gateway, clients talk to many APIs directly — a complex, repetitive setup where every service reinvents authentication, logging, and error handling. With a gateway, clients talk to one endpoint, which fans out to multiple services behind the scenes: simple, secure, and centrally managed.

Key reasons:

Security – centralized authentication, authorization, and rate limiting
Simplified routing – one endpoint for all backend services
Monitoring & logging – unified tracking of API requests
Consistency – common policies across services, including headers, versions, and error handling
Performance – offloads repeated logic from microservices
Scalability – easy to add or remove services behind the gateway

Load Balancer vs. API Gateway

It’s tempting to assume a load balancer already does this job. It doesn’t — a load balancer distributes traffic, but it doesn’t inspect, secure, or transform it. An API Gateway like Kong can go further by applying policies to incoming API requests.

Example 1 — Rate Limiting & Authentication

Feature	Load Balancer	API Gateway
Rate Limiting	Requests reach the backend and can cause overload.	Requests can be limited, for example, to 3 req/sec. Excess requests can be blocked with `429 Too Many Requests`.
Authentication	Invalid tokens are forwarded and the backend must reject them.	Invalid tokens can be blocked at the gateway with `401 Unauthorized`.

Example 2 — Custom Headers

A gateway can inspect and modify request headers. For example:

User-Agent: SmartTVApp/1.0

Kong can process this request and add headers such as:

X-Device-Type: SmartTV
X-Region: IN

Solution Architecture

In this setup, direct client-to-service calls were replaced with a single Kong-fronted entry point. The demo wires together three pieces: a Flask backend exposing several routes, Kong as the gateway that proxies and controls traffic, and Konga as a web UI for configuring Kong without hand-writing API calls.

Components:

Component	Role	Key Capability
Flask App	Backend microservice	Serves application routes
Kong Gateway	API Gateway / reverse proxy	Request routing, plugins, and security
Konga	Admin UI for Kong	Visual configuration of services, routes, and plugins
Docker on AWS EC2	Deployment layer	Containerized and portable deployment

This means clients only ever talk to Kong’s proxy port — routing to the right backend happens behind the scenes.

Visual: Insert the Flask–Kong–Konga architecture diagram here.

Prerequisites

Before wiring Flask, Kong, and Konga together, ensure the following are available:

A running Flask application exposing the target routes
Docker and Docker Compose installed
Kong Gateway container with its datastore, such as Postgres
Konga container, pointed at the Kong Admin API
An AWS EC2 instance to run the containers
Network access between Konga, Kong, and the Flask backend

Flask backend endpoints used in the demo:

/home → Home page
/web → Web section
/support → Support page
/about → About us
/offers → Promotional offers

Step 1 – Log In to Konga and Connect Kong

Open the Konga UI and point it at the Kong Admin API so it can manage services, routes, and plugins. On first launch, Konga prompts you to create an administrator account.

Konga URL: http://<host>:1337
Kong Admin API: http://<host>:8001

Check that Kong is reachable before proceeding:

curl -i http://<host>:8001/status

Step 2 – Create a Service

A Service in Kong represents an upstream backend — in this case, the Flask application. This is created from the Konga UI through Services → Add Service.

name: flask-service
url: http://flask-app:5000

Step 3 – Add Routes

Routes map incoming paths on the gateway to the service created above. Each Flask endpoint gets a corresponding route on Kong.

route: /home     → flask-service
route: /web      → flask-service
route: /support  → flask-service
route: /about    → flask-service
route: /offers   → flask-service

Step 4 – Proxy Traffic Through Kong

Requests now go through Kong’s proxy port instead of hitting Flask directly:

curl http://<host>:8000/home
curl http://<host>:8000/offers

All traffic to the Flask app now flows through a single, controllable entry point.

Plugin Enablement — Rate Limiting & Authentication

Everything below is configured through the Konga UI, backed by Kong’s Admin API — no custom gateway code required.

Rate Limiting Plugin

Controls how many requests are allowed in a time window
Can be applied per Service, per client IP, or per custom Header
Example configuration: 3 requests/sec, 10 requests/min

plugin: rate-limiting
config:
  second: 3
  minute: 10
  policy: local

Authentication Plugin (Key Auth)

Enables key authentication — clients must send a valid key
Protects sensitive routes and APIs
Applied at the service or route level
Ensures only authorized users reach backend services

plugin: key-auth
config:
  key_names:
    - apikey

With both plugins enabled, an unauthenticated or over-limit request is rejected by Kong before it ever reaches Flask.

Benefits Achieved

After centralizing traffic through Kong, a few operational improvements stood out:

Authentication and rate limiting enforced in one place instead of per-service
Invalid tokens and excess requests rejected before reaching the backend
Consistent header handling and request transformation across all routes
One place to monitor and log all API traffic
Easy to add new backend services without duplicating security logic
Fully containerized, reproducible deployment on Docker/EC2

Instead of every microservice reinventing authentication and rate limiting, Kong now enforces it centrally for all of them.

Best Practices

Practice	Why It Matters
Apply rate limiting on every public route	Prevents abuse and protects backend services from overload.
Use Key Auth or JWT/OAuth2 on sensitive routes	Blocks unauthorized traffic before it reaches the backend.
Centralize logging via Kong plugins	Provides one place to monitor API traffic.
Version routes explicitly, such as `/v1/` and `/v2/`	Allows backend services to evolve without breaking existing clients.
Containerize Kong, Konga, and backend services	Simplifies scaling and keeps environments reproducible.

Conclusion

An API Gateway turns a sprawl of individually-managed microservices into a single, secure, and observable surface. Kong provides the high-performance routing and plugin ecosystem, Konga makes that configuration approachable through a UI, and Flask stands in for any backend microservice needing protection.

Together, they replace scattered per-service authentication and rate-limiting logic with one centrally managed layer that simplifies API management and provides a consistent way to control traffic across services.

If you’re running multiple backend services behind ad-hoc authentication and rate-limiting logic, Kong is worth evaluating as a centralized API Gateway. Start with a small set of routes in a non-production environment, validate the plugin behavior, and gradually expand coverage across your services. If you’re already using Kong or are considering an API Gateway, please share your experience or questions in the comments – I’d love to hear how you’re managing your microservice traffic.