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 propose an architecture for your project. Order Kong implementation and get a reliable API gateway from scratch.