Tomada de Decisão Técnica
Ponderar alternativas explicitamente, escolhendo a opção que envelhece bem em vez da que entrega mais rápido.
evidenciada em: 5 estudos de caso · 1 empresas
documentos comprobatórios
Fundando um serviço de analytics ao mover relatórios para fora do banco transacional
Fundei um novo serviço de relatórios que separa leituras analíticas pesadas do banco de dados transacional, resolvendo timeouts de indicadores, enquadrando o trade-off OLTP-vs-OLAP, revisando criticamente a decisão de arquitetura, e construindo o walking skeleton e sua camada de dados.
Desenhando um único caminho de computação para uma métrica entre serviços
Dois serviços calculavam de forma independente a mesma métrica voltada ao cliente, causando dados inconsistentes. Redesenhei a arquitetura para que só um serviço fosse dono do cálculo enquanto todo outro serviço simplesmente sinalizava dados desatualizados.
Desenhando as garantias de segurança para uma limpeza orquestrada por IA, não só automatizando o trabalho braçal
Desenhei e construí uma skill de Claude Code que orquestra com segurança agentes paralelos para remover feature flags expiradas em um frontend compartilhado e dois serviços de backend, fechando um épico de limpeza de 36 subtarefas (24 feature flags mais 3 tours de produto expirados e uma página legada, ~3.100 linhas removidas em um único commit), com batching por conjuntos de arquivos disjuntos para que agentes não possam colidir, validação por diff contra baseline em vez de aprovação/reprovação absoluta, e uma ordem de deploy entre dois repositórios reforçada para que mudanças de infraestrutura nunca possam preceder o código do qual dependem.
Tornando o hardening de containers e dependências uma prática permanente, não uma resposta a auditoria
Transformei o hardening de containers e dependências em uma prática trimestral permanente em dois serviços de backend ao longo de quatro trimestres, cobrindo runtimes non-root, 135 CVEs sinalizados e todos os 7 classificados como críticos remediados na primeira passagem, depois uma revisão de imagem base e dependências que levou a auditoria de 69 achados para 16, CVEs de SO sem correção de 160 para 0, e a imagem final de 1,64 GB para 463 MB, com risco aceito baseado em explorabilidade documentado em vez de números de versão perseguidos, e uma regressão de rollout autoinfligida com causa raiz identificada e corrigida no mesmo dia.
Mudando onde um novo estado é tratado, em vez de ensinar oito caminhos de leitura sobre ele
Um novo estado operacional de ativo, válido para toda a plataforma, foi especificado como uma regra que oito caminhos de leitura diferentes tinham que aprender. Propus aplicá-la uma única vez na fronteira de escrita, removendo o ativo do escopo da rota e restaurando-o na reativação, o que tornou a maior parte do escopo original desnecessária e deixou contadores, relatórios, sincronização com o app e adherence intocados.
exercida em