Entendendo na Prática: o que e API Gateway

O que e API Gateway

API Gateway e o ponto de entrada único para todos os clientes de um sistema de microservicos.

API Gateway e um componente que age como porta de entrada para todas as requisições dos clientes. Em vez de cada cliente conhecer o endereco de cada microservico, ele faz todas as chamadas para o gateway, que se encarrega de rotear para o serviço correto. Além do roteamento, o gateway centraliza responsabilidades transversais que seriam redundantes em cada serviço: autenticação, rate limiting, logging, cache e transformação de requisições e respostas. Sem um API Gateway, cada microservico precisária implementar essas funcionalidades por conta própria, gerando duplicação de código e comportamentos inconsistentes. O gateway simplifica a vida dos clientes e libera os serviços para focar exclusivamente na lógica de negócio específica de cada dominio.

Como funciona o roteamento

O gateway mapeia cada rota para o microservico responsável e encaminha a requisição.

O roteamento e a função mais básica do API Gateway. Uma requisição GET /pedidos/123 e recebida pelo gateway, que verifica sua tabela de rotas e encaminha para o serviço de Pedidos. Uma requisição POST /pagamentos e redirecionada para o serviço de Pagamentos. O cliente não precisa saber que existem microservicos separados: para ele, e tudo a mesma API. O gateway pode transformar a requisição antes de encaminhar: mudar o path, adicionar headers, agregar respostas de múltiplos serviços em uma única resposta. Esse padrão de agregação e especialmente util para reduzir o número de chamadas que o cliente frontend precisa fazer, melhorando a performance especialmente em conexões moveis.

Autenticação e autorização no gateway

Validar o token JWT uma vez no gateway evita duplicar essa lógica em cada serviço.

Um dos maiores beneficios do API Gateway e centralizar a autenticação. Sem gateway, cada microservico precisária validar o token JWT recebido nas requisições, duplicando código e criando risco de inconsistências. Com o gateway, a validação acontece uma única vez: o gateway verifica a assinatura e a expiração do token antes de encaminhar a requisição. Se o token for inválido, a requisição e rejeitada no gateway sem nem chegar ao serviço. O gateway pode também enriquecer a requisição com informações do usuário extraidas do token, adicionando headers como X-User-Id e X-User-Role para os serviços downstream, que recebem a requisição ja autenticada e podem confiar nos headers sem reprocessar o token.

Rate limiting e throttling

Limitar requisições por cliente ou IP no gateway protege os microservicos de sobrecarga.

Rate limiting e a capacidade de limitar quantas requisições um cliente pode fazer em um período de tempo. Implementar isso em cada microservico seria complexo e inconsistente. No gateway, e centralizado: cada cliente ou IP pode fazer no máximo 100 requisições por minuto. Quando o limite e excedido, o gateway retorna 429 Too Many Requests sem encaminhar a requisição para os serviços. Isso protege os serviços de ataques de negação de serviço e de clientes com bugs que fazem chamadas excessivas. O gateway pode ter limites diferentes por rota, por plano de API ou por cliente. Ferramentas como Kong, AWS API Gateway e NGINX oferecem rate limiting configurável sem necessidade de código customizado adicional.

Load balancing no gateway

O gateway distribui as requisições entre múltiplas instâncias do mesmo serviço.

Quando um microservico tem múltiplas instâncias para suportar a carga, o gateway faz load balancing distribuindo as requisições entre elas. O algoritmo mais comum e round-robin: a primeira requisição vai para a instância 1, a segunda para a instância 2, e assim por diante. O gateway pode também usar algoritmos mais sofisticados como least connections, que envia para a instância com menos conexões ativas. O load balancing no gateway e complementar ao Service Discovery: o gateway precisa saber quais instâncias estão disponíveis e saudáveis, integrando com o registry de serviços para obter essa informação em tempo real e não encaminhar requisições para instâncias que estão fora do ar.

BFF, Backend for Frontend

Um gateway especializado por tipo de cliente entrega exatamente o que cada cliente precisa.

O padrão BFF, Backend for Frontend, e uma evolução do API Gateway onde em vez de um único gateway para todos os clientes, existe um gateway especializado por tipo de cliente: um para o app mobile, um para o web browser, um para parceiros externos. Cada BFF conhece as necessidades específicas do seu cliente e pode agregar, transformar e otimizar as respostas de acordo. O app mobile precisa de payloads menores e menos dados. O web browser pode consumir APIs mais ricas. Os parceiros tem contratos de API estáveis e versionados. O BFF evita que o gateway genérico tente servir a todos com um meio-termo que não atende bem ninguem, melhorando performance e clareza dos contratos de API.

Exemplos reais: Netflix e Uber

Netflix e Uber usam API Gateway para unificar o acesso a centenas de microservicos.

A Netflix tem centenas de microservicos atras de um API Gateway que serve milhões de dispositivos simultaneamente. O gateway da Netflix, baseado no Zuul e depois no Spring Cloud Gateway, roteia requisições, aplica autenticação e coleta métricas de forma centralizada. A Netflix popularizou o padrão BFF com gateways especializados por tipo de dispositivo: TV, mobile, web. O Uber tem um API Gateway que serve clientes, motoristas e parceiros, cada um com necessidades diferentes de API. O gateway aplica regras de autorização específicas para cada tipo de usuário e agrega dados de múltiplos serviços internos em uma única resposta otimizada para cada tipo de cliente.

Quando usar API Gateway

Qualquer sistema com mais de dois ou tres microservicos se beneficia de um API Gateway.

Um API Gateway faz sentido quando: você tem múltiplos microservicos e quer simplificar o acesso dos clientes; precisa de autenticação centralizada sem duplicar código; tem requisitos de rate limiting ou throttling; precisa de logging e tracing centralizados; ou tem clientes com necessidades diferentes que se beneficiariam do padrão BFF. Para sistemas simples com um ou dois serviços, o overhead de um gateway pode não valer a pena. Mas conforme o sistema cresce e ganha mais microservicos e mais tipos de clientes, a ausência de um gateway se torna um problema real: cada cliente precisa conhecer cada serviço e cada serviço precisa implementar as mesmas funcionalidades transversais repetidamente.

Vantagens e cuidados

Centralização simplifica, mas o gateway não pode virar um gargalo ou um monolito escondido.

As vantagens são: ponto único de entrada para clientes, centralização de autenticação e rate limiting, desacoplamento entre cliente e microservicos, facilidade para versionamento de API e observabilidade centralizada. Os cuidados: o gateway não deve conter lógica de negócio, apenas funcionalidades de infraestrutura. Se o gateway começar a ter regras de negócio, vira um monolito disfarçado de gateway. Outro cuidado e a disponibilidade: o gateway e um single point of failure e precisa ser altamente disponível. Deploy de múltiplas instâncias com load balancer na frente e obrigatório em produção. Evite transformações complexas de dados no gateway, agregações simples são aceitáveis, mas processamento pesado deve ficar nos serviços especializados.

Resumo

API Gateway e o componente que torna sistemas de microservicos viáveis para clientes externos.

API Gateway centraliza o acesso a microservicos, simplificando a vida dos clientes e dos próprios serviços. Roteia requisições, centraliza autenticação, aplica rate limiting, faz load balancing e oferece um ponto único de observabilidade. O padrão BFF estende o conceito com gateways especializados por tipo de cliente. Ferramentas como Kong, AWS API Gateway, NGINX e Spring Cloud Gateway oferecem essas funcionalidades de forma configurável. O gateway não deve ter lógica de negócio e precisa ser altamente disponível. Para qualquer sistema com mais de dois microservicos acessados por clientes externos, um API Gateway não e um luxo, e uma necessidade arquitetural que simplifica e protege todo o sistema.