Estudos de Caso
16 estudos de caso documentados
Contexto, restrições, alternativas, decisão, trade-offs. Nunca só o resultado.
Confirmar o envio das respostas e processá-las com segurança depois
Desenhei e conduzi com apoio do time um fluxo para que inspetores recebessem confirmação assim que as respostas fossem validadas e armazenadas, enquanto o processamento pesado acontecia em segundo plano. A caixa de saída mantém cada grupo rastreável e reprocessável; o resultado é qualitativo, sem métrica antes e depois.
Medindo defeitos de aderência às rotas antes de mudar a produção
Investiguei relatos sobre aderência às rotas antes de propor uma mudança. Consultas de leitura em produção e reproduções em staging mostraram que meu primeiro critério era amplo demais; revisei a medição e usei os resultados para orientar correções específicas. As contagens são de populações diferentes, e a tendência pós-release era uma medida do time.
Tirar os relatórios do banco transacional
Indicadores para clientes sofriam timeout porque consultas analíticas disputavam recursos com o tráfego da aplicação. Escrevi a decisão para separar as cargas, revisei a análise inicial para considerar a latência do warehouse e ajudei outro engenheiro a estabelecer a base do serviço. A implantação está em andamento; a latência final ainda não foi medida.
O incidente de permissões — e o deadlock separado que apareceu depois
Uma mudança de limpeza de roles que implementei tratava o acesso como global e o removeu entre workspaces. Assumi a resposta ao incidente, documentei a regra ausente e conduzi a direção arquitetural de um consumer substituto entregue pelo squad. Meses depois, investiguei um deadlock diferente ligado ao particionamento do Kafka e contribuí para o lock por usuário e o tratamento recuperável de falhas; a taxa posterior de erros não foi medida.
Trocando um join em tempo real por uma coluna materializada, depois encontrando os 79% que minha própria migração deixou para trás
Um join do warehouse por requisição estava escaneando 658,8 MB contra um teto rígido de 953,7 MiB por job, em uma tabela que cresce a cada novo cliente. Medi, movi o join para o pipeline que já o executava, deletei o cache que escondia o problema, depois auditei minha própria migração e encontrei 79% das linhas de produção nunca preenchidas retroativamente, mais 9.299 alertas que nunca tinham aparecido no produto.
Corrigindo dados de produção com segurança, com ferramentas reversíveis e auditáveis
Corrigi dezenas de milhares de registros corrompidos em produção (~33k em um caso) sem janela de manutenção, usando comandos CLI reutilizáveis com dry-run, arquivos de rollback, auditoria em lote e republicação de eventos, um padrão de "comando de correção" que o time depois reutilizou.
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 uma suite end-to-end instável determinística sem esconder falhas
Transformei uma suite end-to-end não determinística (25 a 37 falhas variando por execução) em 302 passando com zero falhas (8 skips pré-existentes deixados intocados, e o consumer rodando), sem adicionar um skip ou enfraquecer uma asserção, e, em review, provei empiricamente que três das quatro mudanças de produção propostas eram desnecessárias.
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.
Sincronizando uma Edição de Dados Entre Serviços de Forma Atômica
Fiz uma edição em um nó organizacional na hierarquia de ativos se propagar de forma consistente entre cópias desnormalizadas em sete tabelas e dois serviços, via uma única transação atômica com eventos pós-commit, o trabalho que me tornou a referência do time em sincronização entre serviços.
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.
Busca em hierarquias de ativos: contribuição no backend de uma funcionalidade compartilhada
Navegar por uma hierarquia grande exigia consultas repetidas e carregava devagar. Contribuí com a travessia recursiva no backend, reduzindo o padrão de N×3 chamadas sequenciais para três consultas. Outro engenheiro fez a maior parte da tarefa final de busca. A funcionalidade trouxe busca contextual e prefetch; a latência antes e depois não foi medida.
Introduzindo um Design System onde não existia nenhum
Identifiquei a ausência de padrões frontend, propus um Design System, construí-o do zero e ensinei o time a adotá-lo.
Trazendo observabilidade de erros para um time que não tinha nenhuma
Dei a um time que não tinha nenhum monitoramento de erros uma prática estruturada de observabilidade construída a partir de um reporter compartilhado e um interceptor de API com tagging em tempo de requisição mais dashboards e um fluxo de triagem, transformando bugs de produção de algo reportado pelo suporte em algo que o time pode ver e priorizar.
Escolhendo a altitude certa para corrigir um bug encontrado em review, não só o patch mais rápido
Em code review, identifiquei um bug de null-safety que teria derrubado três componentes de produção, e corrigi a classe do defeito em vez das três instâncias, propondo um helper compartilhado na camada de dados para a autora do PR em vez de aplicar patch em cada ponto de renderização eu mesma; um dos 310 pull requests em que dei um veredito explícito de review naquele semestre (702 em quatro repositórios entre 2025-03 e 2026-08), medido a partir da API do Bitbucket em vez de lembrado de memória.