Eduardo André Zicato; Anderson Canale Garcia

DOI: 10.22167/2675-6528-202600740

Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Resumo

A adoção de arquiteturas de microsserviços no desenvolvimento de software corporativo gerou a necessidade de soluções eficazes para o gerenciamento de APIs. Objetivou-se realizar uma análise comparativa entre os principais API gateways open source Kong, Apache APISIX, KrakenD e Nginx, avaliando seu desempenho, consumo de recursos e conjunto de funcionalidades em ambiente controlado e padronizado. A metodologia consistiu na criação de um framework de testes automatizado, utilizando Docker, K6 e Prometheus/Grafana, no qual foram executados cenários de baixa carga (100 usuários), carga média (500 usuários) e teste de stress (1.000 usuários), cada um com duração de cinco minutos. Os resultados demonstraram que o KrakenD apresentou os menores valores de latência média e o maior throughput em cenários de alta concorrência. O Kong destacou-se pela riqueza do ecossistema de plugins e maturidade operacional, enquanto o Apache APISIX revelou um equilíbrio entre desempenho e extensibilidade. O Nginx, por sua vez, exigiu maior esforço de configuração para funcionalidades avançadas. Concluiu-se que a seleção do API gateway mais adequado é intrinsecamente dependente do contexto arquitetural, do perfil de carga e das necessidades específicas de cada projeto.

Palavras-chave: Arquiteturas distribuídas; Benchmark; Desempenho; Gerenciamento de APIs; Open source.

1. Introdução

A transformação digital impulsiona a adoção de arquiteturas de software mais flexíveis e escaláveis, e nesse contexto, os microsserviços consolidaram-se como um padrão amplamente difundido no desenvolvimento de software corporativo. Essa abordagem arquitetural, que fragmenta aplicações monolíticas em serviços menores e independentes, oferece vantagens significativas em termos de agilidade, resiliência e capacidade de evolução. Contudo, a descentralização inerente aos microsserviços introduz complexidades adicionais no gerenciamento da comunicação entre os diversos componentes e os clientes externos.

Para mitigar essas complexidades, os API gateways emergem como um padrão arquitetural essencial. Eles atuam como um ponto de entrada unificado para todas as requisições, centralizando responsabilidades cruciais que, de outra forma, estariam dispersas e replicadas em cada microsserviço individualmente (Newman, 2021). Entre as funções primordiais de um API gateway estão a autenticação e autorização de requisições, o controle de taxa (rate limiting), o balanceamento de carga, a transformação de dados e a observabilidade.

A implementação de um API gateway adequado é fundamental para reduzir o acoplamento entre clientes e serviços, simplificar a topologia de rede e permitir a evolução independente de cada serviço sem impactar diretamente os consumidores da aplicação. A relevância estratégica desses componentes é corroborada pelo crescimento expressivo do mercado de gerenciamento de APIs, que, segundo o relatório da Kong Inc., projeta um crescimento médio de 35% ao ano entre 2023 e 2025. Esse cenário reflete a expansão contínua dos modelos de negócio baseados em plataformas digitais e a crescente consolidação de arquiteturas orientadas a serviços nas organizações.

O mercado de API gateways oferece uma vasta gama de soluções, com destaque para as alternativas de código aberto, que se distinguem por suas características arquiteturais e perfis de desempenho. Entre as opções mais proeminentes e amplamente utilizadas no ecossistema open source, encontram-se o Kong Gateway, o Apache APISIX, o KrakenD e o Nginx, este último frequentemente empregado como gateway por meio de módulos como o OpenResty e o NGINX Plus. A diversidade dessas ferramentas, embora benéfica, impõe um desafio considerável aos engenheiros de software na escolha da solução mais alinhada aos requisitos específicos de cada projeto.

Apesar da importância crítica dessa decisão, a literatura técnica e os recursos disponíveis para auxiliar na seleção de um API gateway apresentam lacunas significativas. Muitos dos estudos comparativos existentes são conduzidos pelos próprios fornecedores das soluções ou por comunidades com potenciais vieses de interesse, o que pode comprometer a imparcialidade dos resultados. Além disso, essas análises frequentemente falham em contemplar cenários realistas de uso em produção, limitando sua aplicabilidade prática.

Outra limitação observada nas comparações disponíveis é a raridade de estudos que combinam métricas de desempenho quantitativas, como latência e throughput, com uma avaliação qualitativa abrangente das funcionalidades e da experiência de uso. Essa deficiência dificulta a tomada de decisão baseada em evidências por parte das equipes de engenharia, que necessitam de uma visão holística para selecionar a ferramenta mais adequada, considerando tanto os aspectos técnicos quanto os operacionais e de manutenção.

Diante da ausência de estudos comparativos independentes, atualizados e metodologicamente rigorosos que abordem de forma integrada o desempenho, o consumo de recursos e as funcionalidades dos principais API gateways open source, justifica-se a necessidade de uma pesquisa aprofundada. O presente trabalho tem como objetivo realizar uma análise comparativa entre o Kong, Apache APISIX, KrakenD e Nginx, avaliando seu desempenho, consumo de recursos e conjunto de funcionalidades por meio de benchmarks executados em ambiente controlado e padronizado, fornecendo subsídios técnicos para a tomada de decisão em projetos de arquitetura de microsserviços.

2. Material e Métodos

A pesquisa foi conduzida por meio de uma análise de literatura selecionada sobre o tema e de experimentos quantitativos e qualitativos com caráter aplicado. O objetivo central foi realizar uma análise comparativa entre os principais API gateways open source, avaliando seu desempenho, consumo de recursos e conjunto de funcionalidades em um ambiente controlado e padronizado.

A revisão bibliográfica abrangeu publicações científicas, documentações técnicas oficiais e relatórios de benchmarks publicados entre 2019 e 2025. As fontes foram obtidas nas bases de dados IEEE Xplore, ACM Digital Library e Google Scholar, utilizando os descritores “API gateway”, “microservices”, “open source”, “benchmark” e suas combinações para a busca.

Para a análise, foram selecionadas quatro soluções de API gateway open source: Kong Gateway versão 3.5, Apache APISIX versão 3.6, KrakenD versão 2.5 e Nginx versão 1.25 com módulo OpenResty 1.21. A seleção dessas ferramentas baseou-se em critérios de popularidade, especificamente o número de estrelas acima de 10.000 no repositório GitHub.

Todos os experimentos foram executados em um ambiente controlado e isolado, orquestrado por meio do Docker Compose, garantindo que os serviços fossem inicializados em rede isolada com limites de recursos idênticos para cada gateway. O ambiente utilizou contêineres Docker com Kubernetes, gerenciados pela ferramenta Kind (Kubernetes in Docker) versão 0.20.

O cluster de experimentação foi provisionado em um servidor dedicado com as seguintes especificações: processador Intel Core i9-13900K (24 núcleos), 64 GB de memória RAM DDR5 e armazenamento em NVMe de 1 TB. O sistema operacional utilizado foi o Ubuntu 22.04 LTS.

Um microsserviço de referência foi implementado em Node.js 24 (LTS) utilizando o framework Fastify 4.x. Este serviço expôs um único endpoint de API REST (`GET /api/status`) que retornava uma carga útil JSON fixa de 512 bytes, eliminando a variabilidade de processamento no backend e isolando o desempenho medido exclusivamente ao overhead de cada API gateway.

Cada API gateway foi configurado para rotear requisições ao microsserviço de referência. Para o Kong Gateway, utilizou-se o modo DB-less com configuração declarativa em formato YAML. O Apache APISIX foi configurado por meio de sua API administrativa REST. O KrakenD teve sua configuração definida integralmente via arquivo JSON estático. O Nginx, com o módulo OpenResty, foi configurado através do arquivo `nginx.conf`.

Para garantir a equivalência das condições de teste, todos os gateways foram provisionados com os mesmos limites de recursos: 2 núcleos virtuais de CPU e 512 MB de memória RAM. As configurações de cada ferramenta foram mantidas no estado padrão (default) para os parâmetros não relacionados ao roteamento, simulando a experiência de adoção típica de uma equipe sem conhecimento prévio na ferramenta.

O desempenho foi avaliado pelas métricas de latência média, latência no percentil 95 (P95), latência no percentil 99 (P99), throughput (requisições por segundo) e taxa de erros. O consumo de recursos foi mensurado por meio do Prometheus 2.48 em conjunto com o Grafana 10.2, coletando a utilização de CPU (em milicores) e memória RAM em intervalos de 15 segundos durante toda a execução dos testes.

Os testes de carga foram conduzidos com a ferramenta k6 versão 0.48, simulando três cenários distintos: baixa carga (100 usuários virtuais simultâneos), carga média (500 usuários virtuais) e stress test (1.000 usuários virtuais). Cada cenário teve duração de cinco minutos de carga estável, seguidos por 60 segundos de um aumento progressivo e 30 segundos de decremento gradual.

Cada cenário de teste foi repetido três vezes para cada API gateway. Os valores apresentados para as métricas de desempenho e consumo de recursos corresponderam à média aritmética das três execuções de cada cenário, garantindo a robustez dos dados coletados.

Os resultados brutos de cada execução do k6 foram processados e analisados estatisticamente com Python 3.11, utilizando as bibliotecas pandas 2.1, scipy 1.11 e matplotlib 3.8. Foram calculadas médias, desvios-padrão e intervalos de confiança de 95%, e o teste de Kruskal-Wallis foi executado para verificar a significância estatística das diferenças entre os gateways.

Além das métricas de desempenho e consumo de recursos, foram avaliados aspectos qualitativos de cada API gateway. Essa avaliação considerou a facilidade de configuração, a qualidade da documentação e a riqueza do ecossistema de plugins, complementando a análise quantitativa com uma perspectiva operacional.

3. Resultados e Discussão

A análise comparativa dos API gateways open source, conforme delineado no objetivo deste estudo, revelou perfis distintos de desempenho, consumo de recursos e conjuntos de funcionalidades entre Kong, Apache APISIX, KrakenD e Nginx/OpenResty. Os resultados demonstram que a escolha da solução mais adequada é intrinsecamente dependente dos requisitos específicos de cada projeto, como o perfil de carga esperado, a necessidade de extensibilidade e a expertise da equipe de desenvolvimento e operações. Esta seção detalha os achados quantitativos e qualitativos, interpretando-os à luz da literatura e do contexto de arquiteturas de microsserviços.

Inicialmente, a caracterização das soluções avaliadas permitiu compreender suas bases arquiteturais e filosofias de design. O Kong Gateway, lançado em 2015, é construído sobre Nginx e OpenResty, utilizando LuaJIT para alta performance e extensibilidade via plugins. Sua arquitetura é dividida em um plano de dados, para processamento de requisições, e um plano de controle, para gerenciamento de configurações, plugins e rotas, administrável via API RESTful, linha de comando ou painel web (Kong Manager). O Kong Inc. (2024) destaca a riqueza de seu ecossistema de plugins, com mais de 250 extensões para autenticação, autorização, transformação de requisições e integração com service mesh, tornando-o uma escolha preferencial para organizações com demandas empresariais e suporte comercial.

Em termos de persistência, o Kong suporta um modo tradicional com PostgreSQL e um modo DB-less, onde as configurações são declarativas em arquivos YAML ou JSON, carregadas em memória. Este último simplifica o deploy em ambientes Kubernetes, eliminando a dependência de banco de dados externo. A curva de aprendizado do Kong é considerada moderada, exigindo familiaridade com seus conceitos de roteamento e serviços. Essa flexibilidade de configuração e a vasta gama de funcionalidades prontas para uso contribuem para sua popularidade em ambientes corporativos que buscam agilidade no desenvolvimento.

O Apache APISIX, doado à Apache Software Foundation em 2019, também é construído sobre Nginx e OpenResty, mas se diferencia pelo uso do etcd como armazenamento distribuído de chave-valor para configuração. Essa escolha arquitetural confere ao APISIX uma vantagem em alta disponibilidade e configuração dinâmica, pois as alterações de rota, plugins e políticas são propagadas em tempo real para todos os nós do cluster, com latência de propagação inferior a 100 milissegundos. O APISIX (Apache Software Foundation, 2024) suporta mais de 100 plugins nativos e permite extensões em diversas linguagens, como Lua, Go, Python, Java e Node.js, por meio do Plugin Runner, o que amplia sua integração com ecossistemas existentes.

Um diferencial notável do Apache APISIX é o suporte nativo a múltiplos protocolos além do HTTP, incluindo gRPC, MQTT e WebSocket, tornando-o adequado para arquiteturas que combinam APIs REST com comunicação assíncrona e streaming. O projeto possui uma comunidade ativa, especialmente no contexto asiático, e é utilizado em produção por grandes organizações. A documentação oficial é abrangente e o painel administrativo (Apache APISIX Dashboard) oferece uma interface visual para gerenciamento de rotas e plugins, facilitando a operação e a gestão da infraestrutura de API.

O KrakenD, desenvolvido pela Lura Project, destaca-se por não ser construído sobre Nginx, sendo uma aplicação escrita integralmente em Go (Golang). Essa característica lhe confere propriedades específicas de concorrência, um footprint de memória reduzido e ausência de dependências de “runtime” externas (KrakenD, 2024). A filosofia de design do KrakenD é baseada na compilação estática de configuração, onde toda a lógica de roteamento, transformação e agregação de dados é definida em um único arquivo JSON ou YAML, lido na inicialização e compilado em memória. Essa abordagem elimina camadas de abstração em tempo de execução, resultando em latências significativamente menores.

Apesar da vantagem em latência, a configuração estática do KrakenD impõe a limitação de que qualquer alteração requer uma reinicialização do processo do gateway. Um dos recursos mais distintivos do KrakenD é a agregação de backends, que permite combinar respostas de múltiplos microsserviços em uma única resposta para o cliente, reduzindo round-trips e a complexidade do lado cliente. Isso é particularmente útil em arquiteturas Backend for Frontend (BFF). O KrakenD também suporta transformação de respostas via templates Jinja2 e integração com sistemas de autenticação via JWT e OAuth 2.0, embora seu ecossistema de plugins seja menor que o do Kong e do APISIX.

Em termos operacionais, o KrakenD se destaca pela simplicidade de deploy, sendo um único binário estático sem dependências externas, e pelo baixo consumo de memória em repouso, tipicamente inferior a 30 MB. Essa característica o torna adequado para ambientes com restrições de recursos ou arquiteturas de “edge computing”. A ferramenta oferece um plano comunitário (open source) e um plano empresarial (KrakenD Enterprise), com algumas funcionalidades avançadas, como painel de administração visual e suporte a scripts Lua, disponíveis apenas na versão comercial, o que pode ser uma limitação para equipes que dependem de interfaces gráficas.

O Nginx, um servidor web e proxy reverso amplamente difundido, pode ser utilizado como API gateway por meio de configurações avançadas de proxy reverso e do ecossistema OpenResty, que integra o interpretador LuaJIT ao pipeline de processamento do Nginx. Isso permite a implementação de lógicas customizadas de autenticação, roteamento e transformação diretamente no servidor (Reese, 2018). O OpenResty expõe uma API rica para manipulação do ciclo de vida das requisições HTTP, possibilitando a criação de comportamentos sofisticados sem a necessidade de módulos C compilados. Bibliotecas como lua-resty-jwt, lua-resty-redis e lua-resty-http ampliam as capacidades do Nginx para cenários de API management, incluindo validação de tokens e integração com cache distribuído.

Apesar do alto desempenho inerente ao Nginx, sua utilização como API gateway apresenta desvantagens significativas em relação às demais soluções avaliadas. A ausência de um plano de controle centralizado implica que a propagação de alterações de configuração requer a recarga do processo (nginx -s reload) ou reinicialização completa em cenários de mudanças mais profundas. Não há suporte nativo a APIs administrativas RESTful ou painel visual, exigindo que toda a gestão seja feita por meio de arquivos de configuração e scripts. Esse modelo é adequado para equipes com alta expertise em administração de sistemas Unix e Lua, mas representa uma barreira de adoção considerável para equipes menos especializadas.

Comparação de funcionalidades

A avaliação das funcionalidades revelou diferenças significativas entre os gateways. O Kong e o Apache APISIX oferecem configuração dinâmica e painéis administrativos (Kong Manager e APISIX Dashboard, respectivamente), facilitando a gestão. O KrakenD, na versão open source, não possui painel administrativo e sua configuração é estática, exigindo reinicialização para alterações. O Nginx/OpenResty também carece de painel e sua configuração dinâmica é parcial, dependendo de reloads. Em termos de linguagem base para extensões, Kong suporta Lua, Go e JavaScript; APISIX, Lua, Go e Python; KrakenD, Go; e Nginx/OpenResty, Lua (OpenResty).

Ambos Kong e Apache APISIX oferecem autenticação via plugins, enquanto KrakenD e Nginx/OpenResty (via resty-jwt) possuem suporte nativo ou por módulo. O controle de taxa (rate limiting) é implementado por plugins no Kong e APISIX, nativamente no KrakenD e por módulo no Nginx/OpenResty. A agregação de backends é um recurso nativo e distintivo do KrakenD, sendo limitado no Kong e APISIX, e ausente no Nginx/OpenResty. O suporte a gRPC e WebSocket é amplamente presente em Kong, APISIX e KrakenD, com o Nginx oferecendo suporte via proxy.

O modo DB-less é suportado pelo Kong, APISIX (via arquivo) e KrakenD (padrão), enquanto o Nginx/OpenResty também oferece um modo padrão. Em relação ao número de plugins open source, o Kong lidera com mais de 250, seguido pelo APISIX com mais de 100, e KrakenD com mais de 60. O Nginx/OpenResty depende da comunidade para plugins. Todos os gateways, exceto Nginx/OpenResty (parcial), oferecem suporte a OpenTelemetry. A integração com Kubernetes é robusta em Kong (KIC), APISIX (Ingress Controller) e KrakenD (Helm chart), e via Ingress NGINX para o Nginx/OpenResty.

Resultados de desempenho Latência

Os testes de latência, medidos em milissegundos, demonstraram que o KrakenD consistentemente apresentou os menores valores em todos os cenários de carga. No cenário de baixa carga (100 usuários), o KrakenD registrou uma latência média de 9 ms, um P95 de 17 ms e um P99 de 26 ms. Em contraste, o Kong apresentou 14 ms de latência média, 28 ms de P95 e 41 ms de P99. Essa diferença de aproximadamente 36% na latência média em baixa carga ressalta a eficiência bruta do KrakenD.

No cenário de stress test (1.000 usuários), a vantagem do KrakenD permaneceu significativa, com latência média de 21 ms, P95 de 52 ms e P99 de 78 ms. O Kong, por sua vez, atingiu 31 ms de latência média, 82 ms de P95 e 124 ms de P99, uma diferença de 32% na latência média e 59% no P99. O Apache APISIX posicionou-se como a segunda opção mais eficiente em termos de latência, com 11 ms (100 usuários) e 24 ms (1.000 usuários) de latência média, seguido pelo Nginx/OpenResty (12 ms e 28 ms) e, por último, pelo Kong.

A análise das métricas de cauda (P95 e P99) é crucial para aplicações com acordos de nível de serviço (SLA) restritivos. A disparidade observada, especialmente no P99, é atribuída principalmente ao overhead introduzido pelo mecanismo de “plugins” baseado em execução Lua em tempo real do Kong. Em contrapartida, a abordagem de configuração compilada em memória do KrakenD minimiza esse overhead, resultando em latências significativamente menores e mais consistentes, mesmo sob alta concorrência. Essa característica posiciona o KrakenD como uma opção robusta para cenários de latência crítica.

Resultados de desempenho Throughput e taxa de erros

Em relação ao throughput, medido em requisições por segundo (req/s), os resultados reforçaram a superioridade do KrakenD. No cenário de baixa carga (100 usuários), o KrakenD alcançou 10.200 req/s, enquanto o Kong registrou 7.100 req/s. No cenário de stress test (1.000 usuários), o KrakenD manteve a liderança com 9.100 req/s, uma diferença de aproximadamente 54% em relação ao Kong, que demonstrou 5.900 req/s. O Apache APISIX apresentou um throughput intermediário de 8.700 req/s (100 usuários) e 7.400 req/s (1.000 usuários), enquanto o Nginx/OpenResty alcançou 8.100 req/s (100 usuários) e 6.700 req/s (1.000 usuários).

A taxa de erros no Kong no cenário de “stress test” foi de 1,24%, o que foi notavelmente superior à das demais soluções. Essa taxa de erros pode ser explicada pelo consumo de CPU acima do limite alocado durante picos de carga, levando ao enfileiramento e descarte de requisições. Em todos os cenários de baixa e média carga, todas as soluções mantiveram taxas de erros virtualmente nulas, indicando que a robustez diferenciada entre os gateways se manifesta principalmente sob condições de stress. A capacidade de processar um volume maior de requisições com menor taxa de erros é um indicador crítico da resiliência de um API gateway.

Consumo de recursos computacionais

A análise do consumo de recursos computacionais, especificamente CPU (em milicores) e memória RAM (em MB), revelou que o KrakenD se destacou pelo menor consumo. No cenário de carga média (500 usuários), o KrakenD utilizou em média 428 milicores de CPU e 38 MB de RAM. Este resultado é coerente com sua natureza de binário estático compilado em Go, que elimina o overhead de execução de “runtime scripts” Lua e a dependência de bancos de dados de configuração. O baixo “footprint” de memória do KrakenD é relevante em ambientes de “edge computing” e em clusters com grande número de réplicas do gateway.

O Kong apresentou o maior consumo de recursos, com média de 812 milicores de CPU e 1.890 MB de RAM no cenário de carga média (500 usuários). Esse consumo elevado pode ser atribuído à sua arquitetura baseada em Nginx/OpenResty e ao uso extensivo de plugins em Lua, que introduzem um overhead de processamento. O Apache APISIX demonstrou consumo intermediário, com 674 milicores de CPU e 142 MB de RAM, significativamente inferior ao Kong, graças à eficiência de sua integração com etcd para propagação de configurações, o que evita operações de leitura de banco de dados em tempo de requisição. O Nginx/OpenResty registrou consumo de memória bastante reduzido (68 MB de média), porém com utilização de CPU superior à do APISIX (591 milicores), reflexo da execução de scripts Lua para lógicas de autenticação e roteamento.

Avaliação qualitativa das funcionalidades

Na avaliação qualitativa, o Kong liderou com uma média de 4,5 pontos (em uma escala de 1 a 5), devido à sua maturidade como produto, à boa qualidade da documentação e ao vasto ecossistema de plugins. A facilidade de configuração inicial do Kong foi avaliada em 3 pontos, enquanto a qualidade da documentação e o ecossistema de plugins receberam 5 pontos. A configuração dinâmica (hot reload) e a integração com Kubernetes também foram pontuadas com 5, e o suporte a protocolos alternativos, comunidade e observabilidade nativa com 4 pontos. Essa pontuação reflete a robustez e a abrangência da solução para cenários empresariais.

O Apache APISIX obteve uma média de 4,1 pontos, destacando-se no critério de suporte a protocolos alternativos (5 pontos) e na configuração dinâmica via etcd (5 pontos). A facilidade de configuração inicial foi avaliada em 3 pontos, enquanto a qualidade da documentação, ecossistema de plugins, integração com Kubernetes, comunidade e observabilidade nativa receberam 4 pontos. Essa avaliação ressalta o equilíbrio do APISIX entre desempenho e extensibilidade, com um forte suporte a diferentes protocolos e uma eficiente gestão de configurações em tempo real, tornando-o uma alternativa atraente para arquiteturas heterogêneas.

O KrakenD, apesar do desempenho superior nos benchmarks, obteve uma pontuação qualitativa mais baixa, com média de 3,4 pontos. A facilidade de configuração inicial foi avaliada em 4 pontos, mas a ausência de interface administrativa na versão open source e o modelo de configuração estática, que impõe restrições em ambientes de alta frequência de mudança, impactaram negativamente sua pontuação em configuração dinâmica (2 pontos) e painel administrativo (não aplicável na versão OSS). A qualidade da documentação, ecossistema de plugins, suporte a protocolos alternativos, comunidade e observabilidade nativa receberam 3 ou 4 pontos, indicando que, embora funcional, a experiência de uso pode ser menos completa que a de seus concorrentes.

O Nginx/OpenResty apresentou a menor pontuação qualitativa, com uma média de 2,9 pontos, devido à sua complexidade de configuração e à ausência de facilidades nativas para as funcionalidades comuns de API management. A facilidade de configuração inicial e a configuração dinâmica foram avaliadas em 2 pontos, enquanto a qualidade da documentação, suporte a protocolos alternativos, comunidade e observabilidade nativa receberam 3 ou 4 pontos. A ausência de um painel administrativo e a necessidade de gerenciar configurações via arquivos e scripts exigem uma equipe com alta expertise em administração de sistemas Unix e Lua, o que representa uma barreira de adoção considerável para equipes menos especializadas.

Discussão e análise comparativa

A análise integrada dos resultados quantitativos e qualitativos revela uma diferença fundamental entre desempenho bruto e extensibilidade nas soluções avaliadas. O KrakenD, ao adotar uma filosofia de compilação estática e implementação em Go sem dependências de “runtime” externas, atinge o melhor desempenho bruto e o menor consumo de recursos. Seu perfil o torna mais indicado para equipes que precisam de máxima eficiência em cenários de alta carga, com requisitos funcionais bem definidos e onde a flexibilidade operacional de plugins dinâmicos não é a prioridade principal. A ausência de um painel administrativo na versão open source e a configuração estática são trade-offs para sua performance superior.

O Kong, por sua vez, apresenta o ecossistema mais maduro e o maior catálogo de plugins, conferindo maior agilidade no atendimento a requisitos funcionais variados sem necessidade de desenvolvimento de código customizado. Sua desvantagem em desempenho bruto, com throughput 39% inferior ao KrakenD no stress test, pode ser mitigada por estratégias de escalabilidade horizontal, viabilizadas pela sua estreita integração com Kubernetes por meio do Kong Ingress Controller (KIC). Para organizações que priorizam velocidade de implementação de funcionalidades e contam com infraestrutura elástica, o Kong permanece como uma opção equilibrada, oferecendo um vasto conjunto de recursos prontos para uso e um bom suporte comunitário e comercial.

O Apache APISIX emerge como uma alternativa que concilia desempenho (segundo melhor throughput e latência) com extensibilidade e configuração dinâmica por meio do etcd. Seu suporte nativo a múltiplos protocolos e ao desenvolvimento de plugins em diversas linguagens de programação o torna especialmente atraente para organizações com arquiteturas heterogêneas ou equipes com expertise em Go ou Python, que podem reaproveitá-la no desenvolvimento de extensões customizadas. A capacidade de propagar configurações em tempo real e o bom ecossistema de plugins o posicionam como uma solução versátil e de alto desempenho para ambientes dinâmicos.

O Nginx/OpenResty, embora demonstre performance adequada e eficiência em memória, apresenta a maior complexidade operacional dentre os avaliados. A ausência de uma camada de abstração para API management implica que a equipe precisa implementar e manter manualmente funcionalidades que as demais soluções entregam como plugins prontos para uso, gerando custo de desenvolvimento e manutenção que pode superar o benefício de performance em muitos cenários. Sua adoção como API gateway dedicado é mais adequada para equipes com profundo conhecimento da “stack” Nginx e que já utilizam a ferramenta como servidor web ou proxy reverso na infraestrutura existente, onde a integração com sistemas legados é uma prioridade.

Em síntese, os resultados desta pesquisa confirmam que não existe um API gateway open source universalmente superior, mas sim soluções com perfis otimizados para diferentes necessidades. O KrakenD destaca-se em performance bruta e baixo consumo de recursos, ideal para cenários de latência crítica. O Kong oferece um ecossistema robusto e maturidade operacional, adequado para agilidade e escalabilidade em ambientes Kubernetes. O Apache APISIX apresenta um equilíbrio entre desempenho e extensibilidade, com suporte a múltiplos protocolos e configuração dinâmica. O Nginx/OpenResty, embora performático, demanda maior expertise e esforço de configuração, sendo mais indicado para equipes com conhecimento aprofundado de sua stack e infraestrutura existente. A decisão final deve, portanto, ponderar cuidadosamente esses fatores em relação ao contexto específico do projeto.

4. Conclusão

O presente estudo objetivou realizar uma análise comparativa entre os API gateways open source Kong, Apache APISIX, KrakenD e Nginx, avaliando seu desempenho, consumo de recursos e conjunto de funcionalidades em ambiente controlado. Verificou-se que o KrakenD apresentou os menores valores de latência média e o maior throughput em cenários de alta concorrência, além do menor consumo de recursos computacionais, posicionando-o como a solução de maior desempenho bruto. O Kong destacou-se pela maturidade de seu ecossistema de plugins e pela robusta integração com Kubernetes, oferecendo agilidade na implementação de funcionalidades, embora com maior consumo de recursos e latências superiores. O Apache APISIX revelou um equilíbrio entre desempenho e extensibilidade, com suporte a múltiplos protocolos e configuração dinâmica eficiente via etcd. Por sua vez, o Nginx/OpenResty demonstrou complexidade operacional mais elevada, exigindo maior esforço de configuração para funcionalidades avançadas, sendo mais adequado para complementar infraestruturas existentes.

A principal contribuição deste trabalho reside em fornecer subsídios técnicos baseados em evidências para a tomada de decisão na seleção de API gateways em projetos de arquitetura de microsserviços, explicitando os trade-offs entre desempenho, extensibilidade e facilidade de uso. Conclui-se que a escolha do API gateway mais adequado é intrinsecamente dependente do contexto arquitetural, do perfil de carga esperado e das necessidades específicas de cada projeto. Recomenda-se que equipes de engenharia de software utilizem os resultados e a metodologia apresentados como referência, adaptando os cenários de carga e ponderando os critérios qualitativos conforme as competências da equipe e os requisitos funcionais. Para estudos futuros, sugere-se estender a análise para cenários de alta disponibilidade com múltiplas réplicas, incluir métricas de segurança e avaliar soluções baseadas em service mesh, como Istio e Linkerd.

Referências Bibliográficas

Apache Software Foundation. (2024). Apache APISIX Documentation. Disponível em: <https://apisix.apache.org/docs>. Acesso em: 20 jan. 2026.

Kong Inc. (2023). Kong Gateway Documentation. Disponível em: <https://docs.konghq.com>. Acesso em: 15 jan. 2026.

Kong Inc. (2024). Kong Gateway Documentation. Disponível em: <https://docs.konghq.com>. Acesso em: 15 jan. 2026.

KrakenD. (2024). KrakenD Documentation. Disponível em: <https://www.krakend.io/docs>. Acesso em: 15 jan. 2026.

Newman, S. (2021). Building Microservices: Designing Fine-Grained Systems. 2. ed. O’Reilly Media, Sebastopol, CA, Estados Unidos.

Reese, 2018 [Referência completa não encontrada no documento original]

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy