System Design/04 - Cloud Design Patterns/Design & Implementation2 min
Gateway Offloading
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Mover preocupações transversais para o gateway, tirando-as do código de cada serviço.
| Descarregado para o gateway | Antes vivia em |
|---|---|
| Terminação TLS | Cada serviço |
| Autenticação e validação de token | Cada serviço |
| Rate limiting | Cada serviço |
| Compressão, cache | Cada serviço |
| WAF, filtro de IP | Cada serviço |
| Log de acesso, métricas, tracing | Cada serviço |
| CORS, reescrita de header | Cada serviço |
O ganho estrutural: essas coisas passam a ser configuradas uma vez em vez de reimplementadas em cada linguagem e framework do ecossistema.
Trade-offs
Além de evitar duplicação, o padrão elimina uma classe de inconsistência: sem ele, um serviço valida o token de um jeito, outro de outro, e um terceiro esquece de validar. Centralizar torna a política verificável.
Os custos:
O gateway vira crítico e complexo. Ele acumula TLS, autenticação, rate limit e WAF — e um erro ali afeta tudo. Precisa de redundância, e sua configuração merece o mesmo rigor de deploy que o código.
Criptografia termina no gateway. Se o requisito é TLS fim a fim até o serviço, é preciso re-criptografar internamente (mTLS), pagando o custo duas vezes.
O serviço fica vulnerável se alcançado diretamente. Se ele confia que o gateway já autenticou, qualquer caminho que contorne o gateway é uma brecha. A rede precisa garantir que o serviço só é alcançável por ali — ou o serviço precisa validar de novo, o que anula parte do ganho.
Há também um limite de escopo: regra de negócio não se descarrega. Autorização genérica ("o token é válido") cabe no gateway; autorização específica ("este usuário pode ver este pedido") depende do domínio e pertence ao serviço.
Exemplo prático
Uma plataforma com 12 microserviços em quatro linguagens.
Sem offloading: quatro implementações de validação de JWT, quatro configurações de TLS, quatro bibliotecas de rate limit — e a certeza de que pelo menos uma está desatualizada.
Com offloading, o gateway faz TLS, valida o JWT e injeta X-User-Id como header. Os serviços falam HTTP simples e leem um header.
O que continua sendo deles: decidir se aquele usuário pode acessar aquele recurso. O gateway diz quem é; o serviço decide o que pode.
Relacionado
Parte de Design & Implementation · roadmap.sh/system-design