O Que Significa Kong

O que é o Kong Gateway na prática

Kong é uma API Gateway open source construída sobre NGINX e OpenResty. Ela roda como um proxy reverso entre seus consumidores e os serviços backend, permitindo roteamento, autenticação, rate limiting, transformação de requests e muito mais sem precisar modificar o código das APIs. A arquitetura é baseada em plugins, então a maior parte do comportamento extra vem de módulos que você instala e configura. Existe também a versão enterprise chamada Kong Enterprise, mas a discussão aqui foca na versão community (KGW), que é a mais usada no dia a dia de quem implementa microsserviços em produção.

O que significa kong em termos técnicos

A pergunta o que significa kong geralmente aparece quando alguém ouve o nome pela primeira vez e tenta encontrar um significado. O nome é apenas uma marca. Não tem sigla. Não quer dizer nada em outra língua. Foi escolhido pela equipe fundadora como referência ao King Kong, o personagem de ficção, sem nenhuma conexão profunda com a tecnologia em si. O que importa é o que a ferramenta faz. Kong se comunica com um banco de dados (Cassandra, PostgreSQL ou DKNS) que armazena a configuração. O NGINX lê essa configuração e aplica as regras em tempo real. Plugins como Key Auth, JWT, Rate Limiting, Request Transformer e CORS são implementados como código Lua rodando dentro dos phases do NGINX (rewrite_by_lua, access_by_lua, header_filter_by_lua, etc.).

Configuração básica em produção

Se você está começando do zero, o caminho mais direto é rodar o Kong via Docker Compose com PostgreSQL. A documentação oficial oferece um docker-compose.yml pronto que sobe o serviço do Kong, o banco e o dashboard. Leva cerca de 5 minutos para ter algo rodando localmente. No ambiente produtivo, a configuração mínima que eu recomendo inclui: um cluster de pelo menos três nós do Kong, PostgreSQL em alta disponibilidade com replicação, e o Kong Manager (interface web) habilitado apenas internamente. Sem isso, você vai passar por dores de cabeça depois.

Um detalhe importante que poucas pessoas mencionam: o Kong guarda o estado da configuração no banco de dados, mas também mantém um cache em memória. Quando você faz uma atualização via Admin API ou via declarative config, o Kong recarrega a configuração sem derrubar conexões ativas. Isso é bom. O problema é que em versões anteriores à 3.x, há um bug conhecido onde plugins que manipulam headers podem causar perda de headers em requests muito frequentes durante o reload. Se você estiver usando a versão 2.x, considere fazer upgrade antes de expor isso em produção.

Problema real que encontrei e a solução

Em um projeto recente, tivemos um cenário onde precisávamos aplicar rate limiting por tenant em uma API que já estava em produção há seis meses. O Kong suporta rate limiting nativo através do plugin rate-limiting-advanced, que usa Redis como store. Configurei tudo certinho, testei localmente e funcionou. Quando subimos para o ambiente de staging com tráfego real, começamos a ver latência subindo de 15ms para mais de 800ms em certos picos. O problema não era o Kong em si. Era a configuração do Redis. O plugin de rate limiting faz chamadas síncronas ao Redis para incrementar contadores. Quando o Redis estava em modo single-threaded com latency spikes devido a snapshots automáticos (RDB), cada requisição ficava bloqueada aguardando resposta. A solução foi colocar o Redis em modo (Sentinel) com dois réplicas, desativar snapshots RDB e migrar para apenas AOF com fsync everysec. A latência voltou a 12ms na média.

Outro ponto prático: o Kong Community não suporta rate limiting com precisão de milissegundo. Ele trabalha com janelas fixas de segundos, minutos, horas ou dias. Se você precisa de granularidade sub-segundo, vai precisar de uma solução personalizada com o plugin lua-resty-limit-traffic escrito por conta própria.

Arquitetura de plugins avançados

Aqui vai algo que os tutoriais não ensinam: o order dos plugins importa. Kong executa plugins em sequência definida pelo campo priority na configuração. O plugin de CORS, por exemplo, precisa estar antes do plugin de autenticação se você quer que respostas de OPTIONS sejam processadas corretamente sem passar por validação de token. Se a ordem estiver errada, requests de pré-flight falham e sua aplicação front-end simplesmente para de funcionar em ambientes cross-origin. Também vale saber que o Kong permite criar plugins customizados em Lua com bastante facilidade. Você pode escrever um plugin que lê um header específico, consulta um serviço externo de autorização e decide se permite ou bloqueia a requisição. Isso é útil quando o rate limiting padrão não atende necessidades específicas do seu negócio, como limitar apenas requests que contenham determinados tipos de payload.

Limitações e alternativas

O Kong não é perfeito. A curva de aprendizado inicial é razoavelmente íngreme, especialmente para quem nunca trabalhou com NGINX ou OpenResty. A documentação é boa, mas esparsa em cenários avançados. O gerenciamento de certificados SSL via Admin API pode ser frustrante em larga escala. Se você está lidando com um ecossistema simples, talvez um service mesh como o Istio seja mais apropriado. Se o foco é puramente roteamento e transformação de tráfego com baixa complexidade, o Traefik ou o Envoy podem ser opções mais leves. O Kong brilha quando você precisa de uma gateway centralizada com muitos plugins prontos, governança de APIs e controle granular de tráfego em microsserviços distribuídos.

O download do Kong Gateway.community pode ser feito diretamente pelo site oficial (konghq.com/products/kong-konnect) ou via repositórios oficiais para Debian, RHEL e Docker Hub. A versão atual estável é a 4.x, que traz melhorias significativas de performance e suporte nativo a Konnect, o plano cloud da Kong.