Go em produção

Carga real muda as perguntas

Em laboratório, throughput costuma dominar a conversa. Em produção, previsibilidade e capacidade de explicar o comportamento do sistema importam tanto quanto velocidade.

• Integrações externas com latências e taxas de erro fora do nosso controle.
• Área administrativa com autenticação por cookie e permissões explícitas.
• Observabilidade suficiente para diagnosticar causa, não apenas sintoma.
• Cache híbrido para reduzir custo sem transformar Redis em ponto único de falha.

Limites antes de escala

O bootstrap define o envelope operacional: pools, timeouts, concorrência e health checks são configurados antes que a primeira requisição seja aceita.

• GOMAXPROCS e coleta de lixo ajustados ao perfil real de CPU e memória.
• Pool PostgreSQL com limites de abertura, ociosidade e vida útil.
• Servidor HTTP com body limit, buffers e timeouts deliberadamente finitos.
• Inicialização com readiness: a instância só recebe tráfego quando suas dependências essenciais estão prontas.

“Fila infinita não é resiliência. Sob pico, rejeitar cedo e recuperar rápido é melhor do que acumular trabalho até o processo colapsar.

O caminho quente precisa ser simples

A maior parte do ganho veio de remover trabalho, controlar alocações e impedir que dependências lentas ocupassem recursos indefinidamente.

• Serialização eficiente com validação na fronteira e buffers reutilizáveis.
• HTTP client compartilhado, pooling de conexões e timeouts por etapa.
• Compressão e ETag aplicados quando o custo total justificava o ganho.
• Medição por rota para otimizar somente os pontos que apareciam no perfil real.

Cache é uma estratégia de disponibilidade

Redis reduz o read path, mas não deve controlar sozinho a disponibilidade da API. O desenho inclui fallback local e TTLs coerentes com a volatilidade de cada dado.

• Redis como camada primária, com TTL e política de invalidação explícitos.
• Cache local limitado para manter respostas essenciais durante oscilações.
• Chaves versionadas e métricas de hit, miss, erro e latência.
• Eviction previsível para impedir crescimento silencioso de memória.

“Quando Redis falha, a plataforma degrada capacidade; ela não deveria desaparecer.

Métricas precisam responder perguntas

Dashboards foram desenhados a partir de decisões operacionais: devo escalar, limitar, reverter ou investigar uma dependência?

• Histogramas de latência e contadores de resultado por rota normalizada.
• Tamanho de request e response para detectar payloads anormais.
• Sinais do runtime: CPU, heap, goroutines e pausas de GC.
• SLOs e alertas orientados ao impacto, evitando ruído sem ação possível.

“Normalizar parâmetros de rota evitou cardinalidade descontrolada e manteve o Prometheus utilizável durante incidentes.

Controles próximos da fronteira

A área administrativa usa sessão protegida e RBAC explícito. Autorização permanece no servidor, próxima da operação que protege.

• Cookies HttpOnly, Secure e SameSite de acordo com o fluxo.
• Permissões declarativas e trilha de auditoria para operações sensíveis.
• Limites de payload e validação antes da lógica de negócio.
• Ferramentas de diagnóstico expostas somente em ambientes controlados.

Os erros que mudaram o desenho

Os melhores padrões da plataforma surgiram de falhas observadas. Cada incidente virou uma mudança verificável no sistema, não apenas documentação.

• Cardinalidade de métricas levou à normalização obrigatória de labels.
• Dependência total do Redis levou ao fallback local limitado.
• Retries sem orçamento levaram a backoff, jitter e limite de tentativas.
• Logging excessivo levou a amostragem e níveis orientados ao ambiente.

O que eu verificaria antes do próximo deploy

Performance sustentável é uma propriedade do sistema inteiro e precisa ser protegida por automação.

• Timeouts, pools e limites de corpo cobertos por testes de contrato.
• Cache com fallback, TTL, eviction e telemetria verificáveis.
• Rotas normalizadas e alertas ligados a SLOs claros.
• Readiness, rollback e teste de carga representativo antes do release.