
Em uma arquitetura de microsserviços, cada serviço tem seu próprio endereço, sua própria porta, suas próprias regras de autenticação. O cliente (aplicação web, mobile, terceiro) não deveria precisar conhecer todos esses detalhes – e nem deveria chamar dezenas de serviços diretamente. É aí que entra o API Gateway: o orquestrador invisível que se posiciona entre o cliente e os microsserviços.
Um API Gateway atua como um ponto único de entrada, oferecendo funcionalidades como roteamento, autenticação, rate limiting, cache, observabilidade e muito mais. Neste post, vamos entender o que é um API Gateway, por que você precisa de um (mesmo que não saiba) e como escolher entre as principais opções – incluindo como integrar com microsserviços Go.
O problema: chamadas diretas não escalam
Imagine um e-commerce com serviços de: Catálogo, Estoque, Carrinho, Pagamento, Usuários, Entrega, Notificações. Um aplicativo mobile que precisa montar a tela de checkout teria que fazer chamadas para pelo menos 5 serviços. Isso gera:
- Alta latência (múltiplas viagens de rede)
- Complexidade no cliente (ele precisa saber onde cada serviço está)
- Exposição desnecessária (serviços internos viram APIs públicas)
- Dificuldade de evolução (mudar um endpoint exige atualizar todos os clientes)
Um API Gateway resolve tudo isso.
O que um API Gateway faz?

Funcionalidades típicas:
| Funcionalidade | Descrição | Benefício |
|---|---|---|
| Roteamento | Direciona requisições para o serviço correto | Cliente chama apenas o gateway |
| Autenticação/Autorização | Verifica tokens (JWT, OAuth) antes de encaminhar | Segurança centralizada |
| Rate Limiting | Limita número de requisições por cliente | Protege contra abusos |
| Caching | Armazena respostas frequentes | Reduz latência e carga |
| Agregação | Combina múltiplas chamadas em uma | Menos viagens de rede |
| Logging/Monitoramento | Registra todas as requisições | Observabilidade centralizada |
| Tracing | Injeta headers de tracing distribuído | Rastreabilidade |
| Transformação | Converte formatos (XML→JSON) | Interoperabilidade |
| Circuit Breaker | Desliga serviços problemáticos automaticamente | Resiliência |
Topologias comuns
1. Gateway simples (mais comum)
Um gateway único para todas as requisições. Ideal para médio porte.
2. Gateway por domínio (bounded context)
Um gateway por domínio de negócio (ex: gateway de pagamentos, gateway de produtos). Útil para times independentes.
3. Gateway + Service Mesh (avançado)
O gateway lida com borda (edge); o service mesh (Istio, Linkerd) lida com comunicação interna (mTLS, retry, observabilidade).
Opções de API Gateway (open source e comerciais)
| Nome | Linguagem | Características | Go friendly? |
|---|---|---|---|
| Kong | Lua (NGINX) | Maduro, plugins, grande ecossistema | ✅ (SDK Go para plugins) |
| Traefik | Go | Nativo Kubernetes, configuração dinâmica | ✅ (escrito em Go) |
| NGINX | C | Rápido, configuração estática | 🟡 (config manual) |
| Envoy | C++ | Service mesh, alto desempenho | 🟡 (geralmente via Istio) |
| Apache APISIX | Lua | Rico em plugins, alta performance | ✅ |
| Golang puro (custom) | Go | Controle total, simples | ✅ (ideal para Go teams) |
Exemplo 1: Traefik (recomendado para Kubernetes)
Traefik é escrito em Go, se integra nativamente com Kubernetes e Docker, e oferece descoberta automática de serviços.
Configuração mínima (traefik.yaml):
entryPoints:
web:
address: ":80"
providers:
kubernetesCRD: {}
kubernetesIngress: {}
No Kubernetes, use IngressRoute:
apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
name: api-gateway
spec:
entryPoints:
- web
routes:
- kind: Rule
match: Host(`api.exemplo.com`) && PathPrefix(`/v1/orders`)
services:
- name: order-service
port: 8080
middlewares:
- name: auth-middleware
- name: rate-limit
Middleware de autenticação em Traefik (usando plugin Go ou configuração):
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
name: auth-middleware
spec:
forwardAuth:
address: http://auth-service:8080/verify
authResponseHeaders:
- X-User-ID
Exemplo 2: API Gateway customizado em Go
Para casos simples ou quando você quer controle total, escrever seu próprio gateway em Go é trivial.
package main
import (
"net/http"
"net/http/httputil"
"net/url"
"strings"
)
func main() {
// Mapeamento de rotas para serviços
routes := map[string]string{
"/api/users": "http://user-service:8080",
"/api/orders": "http://order-service:8080",
"/api/payment": "http://payment-service:8080",
}
// Cria um proxy para cada rota
for path, target := range routes {
remote, _ := url.Parse(target)
proxy := httputil.NewSingleHostReverseProxy(remote)
http.HandleFunc(path, func(w http.ResponseWriter, r *http.Request) {
// Adiciona tracing, logs, etc.
logRequest(r)
// Proxy
proxy.ServeHTTP(w, r)
})
}
http.ListenAndServe(":8080", nil)
}
Adicionando autenticação JWT:
func authMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
token := r.Header.Get("Authorization")
claims, err := validateJWT(token)
if err != nil {
http.Error(w, "Unauthorized", http.StatusUnauthorized)
return
}
// Injeta user info no contexto
ctx := context.WithValue(r.Context(), "user", claims.UserID)
next.ServeHTTP(w, r.WithContext(ctx))
})
}
Vantagens do gateway custom em Go: simplicidade, baixa latência, controle total. Desvantagens: você precisa implementar funcionalidades avançadas (rate limiting, circuit breaker, etc.) por conta própria.
Exemplo 3: Kong com plugin Go
Kong permite escrever plugins em Go usando o SDK go-pdk.
package main
import (
"github.com/kong/go-pdk"
"github.com/kong/go-pdk/server"
)
func main() {
server.StartServer(NewPlugin, "0.1", 1000)
}
type Plugin struct {}
func NewPlugin() interface{} {
return &Plugin{}
}
func (p *Plugin) Access(kong *pdk.PDK) {
// Verifica header
token, err := kong.Request.GetHeader("Authorization")
if err != nil || token == "" {
kong.Response.Exit(401, []byte("Unauthorized"), nil)
}
}
Rate limiting e circuit breaker no gateway
No Traefik:
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
name: rate-limit
spec:
rateLimit:
average: 100
burst: 50
---
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
name: circuit-breaker
spec:
circuitBreaker:
expression: "LatencyAtQuantileMS(50.0) > 100"
No Go custom (usando golang.org/x/time/rate):
var limiter = rate.NewLimiter(rate.Limit(100), 50)
func rateLimitMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if !limiter.Allow() {
http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
return
}
next.ServeHTTP(w, r)
})
}
API Gateway e microsserviços Go: uma combinação natural
- Traefik é escrito em Go e é a escolha da Jacobus para a maioria dos projetos Kubernetes.
- Custom gateway em Go é ideal para necessidades simples ou quando você quer evitar overhead de ferramentas complexas.
- Kong tem SDK Go e é ótimo para ambientes com muitos plugins.
Qualquer que seja a escolha, o API Gateway trará mais segurança, observabilidade e simplicidade para seus clientes.
Quando você NÃO precisa de um API Gateway?
- Apenas 1 ou 2 microsserviços – um simples balanceador (NGINX) resolve.
- APIs internas que não são expostas diretamente (comunicação service-to-service).
- Times muito pequenos – a complexidade adicional pode não valer a pena.
Conclusão
O API Gateway é o orquestrador invisível que organiza o caos de microsserviços. Ele centraliza autenticação, roteamento, rate limiting, cache e observabilidade. Em Go, temos opções maduras como Traefik (nativo Go) e a possibilidade de construir gateways custom com poucas linhas de código.
Na Jacobus Software, adotamos Traefik para projetos Kubernetes e, quando necessário, implementamos gateways custom em Go para cenários específicos. O resultado: clientes simples, serviços protegidos e arquitetura que escala.
🚪 Quer um API Gateway para seus microsserviços?
Implementamos Traefik, Kong ou gateways custom em Go – com autenticação, rate limiting e observabilidade desde o primeiro dia.
