Kong API Gateway: JWT, Rate Limiting, and Monitoring Setup

Problem: API management without a centralized gateway

Microservice architecture quickly grows: dozens of endpoints appear, authentication is duplicated, rate limiting is implemented differently in each service, monitoring is fragmented. We've seen teams spend weeks just to agree on log formats and security rules. Kong API Gateway — an open-source solution based on nginx/OpenResty — centralizes these tasks: routing, plugins (JWT, rate limiting, CORS, Prometheus), and declarative configuration. Over 7+ years we have deployed Kong in more than 50 projects, from startups to enterprise.

What problems we solve

• Bloated authentication: each microservice has its own JWT parser — code duplication and bugs. Kong handles authentication, validates JWT at the entry point, and passes internal headers. This reduces service code and increases security.
• Rate limiting "on the knee": limits in code are inflexible and hard to change without redeployment. Kong supports rate limiting with Redis — up to 100,000 requests per minute per consumer, with different policies (local, Redis, cluster).
• Lack of observability: without a single point it is difficult to collect metrics. Kong exports to Prometheus the number of requests, latencies (p50/p99), statuses — straight to Grafana.

How Kong solves the authentication duplication problem

Kong acts as a single entry point: all requests first pass through the gateway, where JWT is validated. If the token is valid, Kong adds headers (x-consumer-id, x-user-id) and forwards the request to the microservice. The service can trust these headers without implementing its own check. This reduces code duplication by 40% and lowers the probability of security errors.

How we configure Kong turnkey

We use Kong 3.x (current version) with PostgreSQL or DB-less mode. Below is a typical stack:

version: '3.8' services: kong-db: image: postgres:15 environment: POSTGRES_DB: kong POSTGRES_USER: kong POSTGRES_PASSWORD: kong_password kong-migration: image: kong:3.5 command: kong migrations bootstrap environment: KONG_DATABASE: postgres KONG_PG_HOST: kong-db KONG_PG_USER: kong KONG_PG_PASSWORD: kong_password depends_on: [kong-db] kong: image: kong:3.5 environment: KONG_DATABASE: postgres KONG_PG_HOST: kong-db KONG_PG_USER: kong KONG_PG_PASSWORD: kong_password KONG_PROXY_ACCESS_LOG: /dev/stdout KONG_ADMIN_ACCESS_LOG: /dev/stdout KONG_PROXY_ERROR_LOG: /dev/stderr KONG_ADMIN_ERROR_LOG: /dev/stderr KONG_ADMIN_LISTEN: 0.0.0.0:8001 KONG_PROXY_LISTEN: 0.0.0.0:8000, 0.0.0.0:8443 ssl ports: - "8000:8000" - "8443:8443" - "8001:8001" depends_on: [kong-migration] 

Using Admin API commands we create services, routes, and plugins. Example: configuring JWT and rate limiting on the users-api service.

# Create upstream service curl -X POST http://localhost:8001/services \ -d name=users-api \ -d url=http://users-service:3000 # Create route curl -X POST http://localhost:8001/services/users-api/routes \ -d 'paths[]=/api/v1/users' \ -d 'strip_path=false' # JWT plugin curl -X POST http://localhost:8001/services/users-api/plugins \ -d name=jwt # Rate limiting with Redis curl -X POST http://localhost:8001/plugins \ -d name=rate-limiting \ -d config.minute=100 \ -d config.hour=5000 \ -d config.policy=redis \ -d config.redis_host=redis \ -d config.redis_port=6379 \ -d config.limit_by=consumer 

_format_version: "3.0" services: - name: users-api url: http://users-service:3000 routes: - paths: - /api/v1/users strip_path: false plugins: - name: jwt - name: rate-limiting config: minute: 100 hour: 5000 policy: redis redis_host: redis redis_port: 6379 limit_by: consumer 

Work process

1. Analysis: we gather requirements — which services, protocols, limits, whether DB-less is needed.
2. Design: routing scheme, choice of plugins, network setup (TLS, segmentation).
3. Implementation: deploy Kong, import configuration (declarative or via Admin API), integrate with CI/CD.
4. Testing: load testing (e.g., 1000 RPS), authentication checks, correctness.
5. Deployment and documentation: we hand over instructions, diagrams, Grafana dashboards. Train the team.

What is included in the work

• Deployment of Kong (Docker/Kubernetes/bare metal)
• Configuration of routing, JWT, rate limiting, CORS, request transformer
• Monitoring: Prometheus + Grafana (dashboard ID 7424)
• Integration with Redis for rate limiting
• Administration documentation
• 2 days of team training
• 2 weeks of post-launch support

Estimated timelines

From 2 business days (basic configuration) to 7 days (with canary deployments, HA, DB-less). The cost is determined individually — contact us for an estimate.

Comparison of Kong operating modes

DB-less mode is simpler to deploy: no database required, configuration is static and reloaded on each change. Dynamic mode with PostgreSQL allows changing settings on the fly via Admin API but adds a point of failure. We help choose the appropriate option for your scenarios: if routes change frequently, choose DB; if configuration is stable, DB-less.

Comparison of popular Kong plugins

Why choose Kong for your API?

Kong is on average 3 times faster than custom solutions in terms of throughput (up to 2 million RPS on a single node) and has a rich plugin ecosystem. We guarantee stability: in our projects, Kong has run without restart for over 6 months.

How we customize Kong to your specifics

For each project we adapt DB-less or dynamic mode, choose plugins (key-auth, OAuth2, IP restriction), configure canary deployments via weighted targets. For example, we distribute traffic 90%/10% between service versions. Contact us for a consultation — we'll offer a free architecture for your project. Order Kong implementation and get a reliable API gateway from scratch.