{"id":82867,"date":"2026-09-09T13:06:03","date_gmt":"2026-09-09T07:36:03","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=82867"},"modified":"2026-09-15T10:33:42","modified_gmt":"2026-09-15T05:03:42","slug":"kong-as-an-api-gateway-centralizing-microservice-traffic-with-konga-and-flask","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/kong-as-an-api-gateway-centralizing-microservice-traffic-with-konga-and-flask\/","title":{"rendered":"Kong as an API Gateway: Centralizing Microservice Traffic with Konga and Flask"},"content":{"rendered":"Introduction<\/h2>\n
As applications move from monoliths to microservices, every new service tends to expose its own API. That sounds fine at first\u2014until 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.<\/p>\n
In one of our MSP infrastructure projects, we set up Kong<\/strong> as a centralized API Gateway in front of a set of backend microservices, using Konga<\/strong> as the visual admin layer and a Flask<\/strong> 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.<\/p>\nIn this blog, we will cover:<\/p>\n
\n- What an API Gateway is and why it is needed<\/li>\n
- How an API Gateway differs from a load balancer<\/li>\n
- The Flask\u2013Kong\u2013Konga architecture<\/li>\n
- Implementation steps<\/li>\n
- Rate limiting and authentication plugins<\/li>\n
- Best practices for running Kong in production<\/li>\n<\/ul>\n
What Is an API Gateway?<\/h2>\n
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.<\/p>\n
What it does:<\/strong><\/p>\n\n- Routes and controls incoming API requests<\/li>\n
- Manages authentication, rate limiting, and caching<\/li>\n
- Provides centralized logging and monitoring<\/li>\n
- Enables versioning, transformation, and security policies<\/li>\n
- Improves performance and simplifies client interaction<\/li>\n<\/ul>\n
Why Do We Need an API Gateway?<\/h2>\n
Without a gateway, clients talk to many APIs directly \u2014 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.<\/p>\n
Key reasons:<\/strong><\/p>\n\n- Security<\/strong> \u2013 centralized authentication, authorization, and rate limiting<\/li>\n
- Simplified routing<\/strong> \u2013 one endpoint for all backend services<\/li>\n
- Monitoring & logging<\/strong> \u2013 unified tracking of API requests<\/li>\n
- Consistency<\/strong> \u2013 common policies across services, including headers, versions, and error handling<\/li>\n
- Performance<\/strong> \u2013 offloads repeated logic from microservices<\/li>\n
- Scalability<\/strong> \u2013 easy to add or remove services behind the gateway<\/li>\n<\/ul>\n
Load Balancer vs. API Gateway<\/h2>\n
It’s tempting to assume a load balancer already does this job. It doesn’t \u2014 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.<\/p>\n
Example 1 \u2014 Rate Limiting & Authentication<\/h3>\n
\n\n\n| Feature<\/th>\n | Load Balancer<\/th>\n | API Gateway<\/th>\n<\/tr>\n |
\nRate Limiting<\/strong><\/td>\n| Requests reach the backend and can cause overload.<\/td>\n | Requests can be limited, for example, to 3 req\/sec. Excess requests can be blocked with 429 Too Many Requests<\/code>.<\/td>\n<\/tr>\n\nAuthentication<\/strong><\/td>\n| Invalid tokens are forwarded and the backend must reject them.<\/td>\n | Invalid tokens can be blocked at the gateway with 401 Unauthorized<\/code>.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nExample 2 \u2014 Custom Headers<\/h3>\nA gateway can inspect and modify request headers. For example:<\/p>\n User-Agent: SmartTVApp\/1.0<\/code><\/pre>\nKong can process this request and add headers such as:<\/p>\n X-Device-Type: SmartTV\r\nX-Region: IN<\/code><\/pre>\nSolution Architecture<\/h2>\nIn 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.<\/p>\n Components:<\/strong><\/p>\n\n\n\n| Component<\/th>\n | Role<\/th>\n | Key Capability<\/th>\n<\/tr>\n | \n| Flask App<\/td>\n | Backend microservice<\/td>\n | Serves application routes<\/td>\n<\/tr>\n | \n| Kong Gateway<\/td>\n | API Gateway \/ reverse proxy<\/td>\n | Request routing, plugins, and security<\/td>\n<\/tr>\n | \n| Konga<\/td>\n | Admin UI for Kong<\/td>\n | Visual configuration of services, routes, and plugins<\/td>\n<\/tr>\n | \n| Docker on AWS EC2<\/td>\n | Deployment layer<\/td>\n | Containerized and portable deployment<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n This means clients only ever talk to Kong’s proxy port \u2014 routing to the right backend happens behind the scenes.<\/p>\n Visual:<\/strong> Insert the Flask\u2013Kong\u2013Konga architecture diagram here.<\/p>\nPrerequisites<\/h2>\nBefore wiring Flask, Kong, and Konga together, ensure the following are available:<\/p>\n \n- A running Flask application exposing the target routes<\/li>\n
- Docker and Docker Compose installed<\/li>\n
- Kong Gateway container with its datastore, such as Postgres<\/li>\n
- Konga container, pointed at the Kong Admin API<\/li>\n
- An AWS EC2 instance to run the containers<\/li>\n
- Network access between Konga, Kong, and the Flask backend<\/li>\n<\/ul>\n
Flask backend endpoints used in the demo:<\/strong><\/p>\n\n\/home<\/code> \u2192 Home page<\/li>\n\/web<\/code> \u2192 Web section<\/li>\n\/support<\/code> \u2192 Support page<\/li>\n\/about<\/code> \u2192 About us<\/li>\n\/offers<\/code> \u2192 Promotional offers<\/li>\n<\/ul>\nStep 1 \u2013 Log In to Konga and Connect Kong<\/h2>\nOpen 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.<\/p>\n Konga URL: http:\/\/<host>:1337\r\nKong Admin API: http:\/\/<host>:8001<\/code><\/pre>\nCheck that Kong is reachable before proceeding:<\/p>\n curl -i http:\/\/<host>:8001\/status<\/code><\/pre>\nStep 2 \u2013 Create a Service<\/h2>\nA Service in Kong represents an upstream backend \u2014 in this case, the Flask application. This is created from the Konga UI through Services \u2192 Add Service<\/strong>.<\/p>\nname: flask-service\r\nurl: http:\/\/flask-app:5000<\/code><\/pre>\nStep 3 \u2013 Add Routes<\/h2>\nRoutes map incoming paths on the gateway to the service created above. Each Flask endpoint gets a corresponding route on Kong.<\/p>\n route: \/home \u2192 flask-service\r\nroute: \/web \u2192 flask-service\r\nroute: \/support \u2192 flask-service\r\nroute: \/about \u2192 flask-service\r\nroute: \/offers \u2192 flask-service<\/code><\/pre>\nStep 4 \u2013 Proxy Traffic Through Kong<\/h2>\nRequests now go through Kong’s proxy port instead of hitting Flask directly:<\/p>\n curl http:\/\/<host>:8000\/home\r\ncurl http:\/\/<host>:8000\/offers<\/code><\/pre>\nAll traffic to the Flask app now flows through a single, controllable entry point.<\/p>\n Plugin Enablement \u2014 Rate Limiting & Authentication<\/h2>\nEverything below is configured through the Konga UI, backed by Kong’s Admin API \u2014 no custom gateway code required.<\/p>\n Rate Limiting Plugin<\/h3>\n\n- Controls how many requests are allowed in a time window<\/li>\n
- Can be applied per Service, per client IP, or per custom Header<\/li>\n
- Example configuration: 3 requests\/sec, 10 requests\/min<\/li>\n<\/ul>\n
plugin: rate-limiting\r\nconfig:\r\n second: 3\r\n minute: 10\r\n policy: local<\/code><\/pre>\nAuthentication Plugin (Key Auth)<\/h3>\n\n- Enables key authentication \u2014 clients must send a valid key<\/li>\n
- Protects sensitive routes and APIs<\/li>\n
- Applied at the service or route level<\/li>\n
- Ensures only authorized users reach backend services<\/li>\n<\/ul>\n
plugin: key-auth\r\nconfig:\r\n key_names:\r\n - apikey<\/code><\/pre>\nWith both plugins enabled, an unauthenticated or over-limit request is rejected by Kong before it ever reaches Flask.<\/p>\n Benefits Achieved<\/h2>\nAfter centralizing traffic through Kong, a few operational improvements stood out:<\/p>\n
|
| | | |