O problema recorrente que todo desenvolvedor enfrenta
Você já reparou que, independentemente do projeto ou da ferramenta, os mesmos erros aparecem sempre? Eu passei os últimos anos tentando consertar isso em sistemas legados e não vou enrolar: a maioria dos problemas já foi resolvida antes, mas o conhecimento fica fragmentado em fóruns, stack overflow e mensagens de WhatsApp esquecidas. Quando você finalmente encontra a solução, percebe que é sempre a mesma história, só que com nomes diferentes. Eu comecei a mapear esses padrões em 2018, depois de passar três semanas tentando corrigir um bug de memory leak que na prática era idêntico a um que eu tinha resolvido em 2015, apenas com uma library diferente no meio. A diferença é que dessa vez eu estava perdido porque não sabia que aquele tipo de problema tem um comportamento consistente entre versões de Node, Python e Go. Decidi documentar tudo em um repositório privado e, com o tempo, vira público.
Por que é sempre a mesma história nos projetos de software
O conceito não é mágica. É apenas a observação de que a maioria dos bugs, gargalos e decisões ruins de arquitetura pertence a um conjunto pequeno de categorias. Tem bug de race condition, tem problema de serialização, tem erro de timezone, tem configuração de rede que quebra em production mas funciona local. São cerca de 40 a 50 padrões que cobrem 80% dos incidentes que eu já vi nos últimos oito anos. O que acontece na prática é que as pessoas reinventam a roda porque não conseguem identificar o padrão por trás do problema. Você abre um ticket dizendo "o deploy falha aleatoriamente" e passa dois dias investigando, quando na verdade é um clássico problema de conexão TCP sendo encerrada prematuramente pelo load balancer. Isso resolve em dez minutos se você sabe o que procurar.
Como construir seu próprio catálogo de padrões recorrentes
Não existe ferramenta pronta para isso. Você mesmo tem que criar. O processo mais eficiente que eu encontrei leva cerca de duas horas por semana e se divide em três partes: registrar, classificar e sintetizar. Registrar significa anotar cada incidente significativo assim que ele acontece. Não depois, não quando tiver tempo. Eu uso um arquivo markdown simples com data, problema, stack tecnológica e resolução. Já tive momentos em que guardei no Google Keep e levei dois meses para organizar, e na prática aquelas anotações viraram lixo porque o contexto tinha sumido.
Classificar é o passo que a maioria das pessoas pula. Você precisaar cada entrada com categorias fixas. As principais que funcionam pra mim são: infraestrutura, linguagem/runtime, banco de dados, segurança, deploy/CI-CD e dados. Uma quinta categoria que eu adicionei recentemente foi "comportamento humano" — inclui problemas de comunicação com outras equipes que geram falhas técnicas, como um contrato de API que mudou sem aviso. Sintetizar quer dizer revisar periodicamente e extrair padrões. Eu faço uma sessão de trinta minutos toda sexta-feira, olho as entradas da semana e tento agrupar as que se parecem. Depois de alguns meses você começa a ver repetições. Eu descobri assim que 60% dos meus incidentes de deploy estavam ligados a variáveis de ambiente não propagadas corretamente entre containers. Só precisei de quatro meses de registros para perceber.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Um caso específico que illustratei bem como isso funciona
No início de 2023, enfrentei um problema com um serviço de filas em RabbitMQ que consumia mensagens de forma intermitente e perdia processamentos inteiro em horários de pico. O sintoma era estranho porque o logs mostravam que as mensagens eram entregues, mas o consumidor não as processava. Passei um dia e meio tentando debugar o código do consumidor, achando que era deadlock ou algum problema de concorrência. A solução estava completamente fora do código. Era o prefetch_count do consumer configurado como 1, enquanto o producer enviava mensagens em lotes muito maiores. O RabbitMQ distribuiria as mensagens de forma desigual entre os consumers e, combinado com o ACK manual mal implementado, mensagens ficavam pendentes e nunca eram processadas. O padrão era o mesmo que eu já tinha visto em Kafka dois anos antes, só que a mecânica era ligeiramente diferente porque cada broker de filas tem sua própria semântica de entrega.
Eu configurei o prefetch para um valor proporcional à capacidade de processamento do consumer, adicionei um monitor de mensagens não-ACKadas e pronto. Levei vinte minutos para resolver algo que parecia complexo. Isso é exatamente o tipo de coisa que o catálogo de padrões ajuda a evitar: você vê o sintoma, identifica a categoria (fila/mensageria) e consulta as resoluções anteriores.
Onde conseguir os materiais e como usar na prática
O repositório com o catálogo organizado está disponível publicamente no GitHub. Você pode fazer download direto do arquivo principal ou clonar o repositório inteiro se quiser contribuir com novos padrões. O link é simples: procure por "padroes-recorrentes-dev" no GitHub ou acesse diretamente pelo perfil do repositório. A maneira mais produtiva de usar isso não é ler tudo de uma vez. É ter o catálogo aberto enquanto trabalha e consultar quando aparecer um problema familiar. Eu costumo usar uma busca por tag no markdown mesmo, que leva menos de dois segundos. Se o problema for novo, você adiciona ao catálogo e aproveita para já documentar a solução antes de esquecer os detalhes.
Limitações que ninguém menciona
Esse approach tem problemas reais que precisam ser considerados. O principal é que padrões ficam desatualizados rapidamente. Uma solução que funcionou para RabbitMQ em 2022 pode não se aplicar mais em 2025 porque o broker mudou o comportamento de prefetch ou adicionou novas features de entrega garantida. Eu recomendo revisar o catálogo a cada seis meses no mínimo. Outro ponto importante é que nem todo problema se encaixa nos padrões existentes. Às vezes o incidente é genuinamente novo, causado por uma combinação rara de fatores. Forçar uma categorização nesse caso só gera confusão. Você precisa ter honestidade intelectual para admitir que algo não tem padrão conhecido e tratar como pesquisa nova.
Uma terceira limitação é que esse método depende de disciplina. Se você não registrar os incidentes imediatamente, perde o contexto e as anotações viram inúteis. Eu conheço equipes que tentaram adotar isso e desistiram em três semanas porque o processo parecia burocrático demais no início. A vantagem aparece depois de alguns meses, quando o acúmulo de registros começa a pagar o investimento de tempo. Se você está num projeto pequeno com poucos incidentes, pode não valer a pena manter o catálogo atualizado. No fim das contas, reconhecer que é sempre a mesma história não é pessimismo, é eficiência. Você para de tratar cada problema como único e começa a tratar como variação de algo que já foi resolvido. O trabalho real é simplesmente manter a memória organizada.
