Nos artigos anteriores da série System Design: da teoria à prática, exploramos fundamentos (Artigo 1), bancos de dados e armazenamento (Artigo 2), confiabilidade e consistência (Artigo 3) e padrões arquiteturais (Artigo 4). Agora chegamos a uma camada essencial para qualquer sistema moderno: observabilidade e operações.
Se arquitetura é o esqueleto e consistência é o coração, a observabilidade é o sistema nervoso. Ela permite sentir dores, identificar anomalias e agir antes que pequenas falhas se transformem em crises. E, junto com ela, vem a necessidade de mecanismos operacionais claros: dead-letter queues, retries, kill switches. Sem isso, a melhor arquitetura do mundo é apenas uma caixa-preta prestes a falhar.
Este artigo cobre cinco princípios fundamentais para dar olhos e mãos ao sistema:
- Tracing > logging.
- Métricas apodrecem sem dono.
- Retries sem backoff = DDoS contra si mesmo.
- Dead-letter queues não são opcionais.
- Levers > knobs.
21. Tracing > logging
Teoria. Logs contam o que aconteceu. Traces contam por que aconteceu. Em sistemas distribuídos, especialmente em microservices, entender o fluxo ponta a ponta é impossível apenas com logs locais. É aí que entra o tracing distribuído: ferramentas como OpenTelemetry, Jaeger e Zipkin permitem ligar eventos em múltiplos serviços e construir a “linha do tempo” de uma requisição.
Essa diferença é mais que técnica, é cultural: times acostumados a logs pensam em eventos isolados; times maduros em tracing entendem o contexto transversal. O trace mostra como o request percorreu a arquitetura, onde perdeu tempo, onde falhou. É literalmente o mapa do território.
Exemplo real. O Uber enfrentou problemas sérios de tail latency até adotar tracing distribuído com Jaeger (desenvolvido internamente e depois open source). O mapeamento revelou gargalos inesperados: serviços aparentemente rápidos, mas que, em cascata, criavam filas ocultas. Sem tracing, ficavam invisíveis.
👉 No Código Simples, o artigo Processamento assíncrono: os desafios da escalabilidade toca nesse ponto: sem observabilidade, filas e mensagens viram buracos negros.
22. Métricas apodrecem sem dono
Teoria. Toda métrica nasce útil, mas morre esquecida se não houver dono. Dashboards acumulam dezenas de gráficos que ninguém olha. Alarmes disparam sem contexto e são ignorados. O resultado? Observabilidade se transforma em ruído.
Métricas precisam de responsabilidade clara: alguém deve responder por elas, revisá-las periodicamente e aposentá-las quando não fizerem mais sentido. Mais importante: precisam estar alinhadas ao que o usuário sente. Latência P95 no backend só é relevante se correlacionada à experiência real.
Exemplo real. No Twitter (hoje X), havia mais de 200 painéis diferentes de métricas de API. Durante incidentes, a equipe perdia tempo navegando. Após um esforço de governança, reduziram para menos de 30 métricas “de ouro” por área, cada uma com um time responsável. O resultado foi menos alarme falso e resposta mais rápida.
23. Retries sem backoff = DDoS contra si mesmo
Teoria. Retries automáticos são necessários. Mas, se mal projetados, podem ser fatais: todos os clientes repetindo a mesma requisição no mesmo intervalo criam o efeito de thundering herd, transformando um problema pequeno em outage completo.
A solução clássica é exponential backoff com jitter: intervalos de retry crescentes e com aleatoriedade. Isso distribui melhor a carga e evita rajadas sincronizadas. O retry precisa ser inteligente: respeitar circuit breakers, parar em falhas definitivas (ex.: 4xx), e ser monitorado como comportamento do sistema, não apenas como fallback do cliente.
Exemplo real. O AWS SDK implementa backoff exponencial com jitter como padrão, justamente porque clientes sem isso já causaram incidentes massivos dentro da AWS. O Google Cloud segue a mesma linha. Empresas que implementam retries sem jitter em escala invariavelmente acabam com DDoS acidental contra si mesmas.
👉 Esse ponto conecta com o artigo Idempotência em software: retries só são seguros se acompanhados de idempotência.
24. Dead-letter queues não são opcionais
Teoria. Em sistemas baseados em mensageria, algumas mensagens sempre falharão. Podem estar malformadas, corrompidas ou depender de condições externas que nunca se concretizam. Sem um destino para essas mensagens, elas ficam eternamente em retry, ocupando espaço e mascarando erros reais.
A DLQ (dead-letter queue) é a lixeira controlada do sistema: um lugar para mensagens “venenosas” serem armazenadas, analisadas e resolvidas manualmente. Não é um recurso opcional, é parte do design.
Exemplo real. Em 2019, o Nubank enfrentou um incidente em que mensagens inválidas ocupavam filas críticas, atrasando todo o processamento de eventos de clientes. A correção foi adotar DLQs sistemáticas em todos os fluxos Kafka, com monitoramento e playbooks claros.
25. Levers > knobs
Teoria. Knobs são controles finos, quase sempre inúteis em crises. Levers são mecanismos de ação rápida: kill switches, feature flags, rate limiters. São eles que permitem reagir a incidentes em minutos, não em horas.
Designar levers desde o início é reconhecer que falhas vão acontecer e que precisamos de botões grandes e claros para contê-las. Rate limits evitam que clientes internos derrubem serviços. Feature flags permitem desligar partes não críticas (ex.: recomendações) para salvar o núcleo (ex.: checkout).
Exemplo real. O Spotify construiu um sistema interno chamado Backstage que, além de gerenciar serviços, centraliza levers operacionais. Durante um incidente de sobrecarga em 2021, bastou acionar um kill switch para desligar recomendações pesadas e preservar o streaming — usuários nem perceberam.
Conclusão — olhos, ouvidos e mãos
Sem observabilidade, estamos cegos, sem métricas confiáveis, estamos mal informados e sem mecanismos de operação, estamos impotentes. Observabilidade e operações são o elo que conecta a arquitetura elegante ao mundo caótico da produção.
Recapitulando:
- Tracing dá contexto, logs sozinhos não bastam.
- Métricas sem dono viram lixo visual.
- Retries ingênuos podem derrubar o próprio sistema.
- DLQs são essenciais para não mascarar erros.
- Levers são a diferença entre um incidente de 5 minutos e um de 5 horas.
Esses princípios lembram que a engenharia não acaba no código, mas no ecossistema que permite operar e evoluir o sistema em segurança.
