Comunicação
Decisões escritas com alternativas; documentos que encerram debates.
evidenciada em: 8 estudos de caso · 3 empresas
documentos comprobatórios
Respondendo a um incidente de produção com a decisão de arquitetura que faltava, não só um patch
Identifiquei a causa raiz de um incidente de produção que bloqueava clientes como uma suposição de arquitetura não documentada, reconstruí o consumer afetado com um post-mortem, um ADR e documentação de regras de negócio, depois, após o rollout expor um deadlock de banco de dados, diagnostiquei-o como uma incompatibilidade de particionamento do Kafka e substituí a perda silenciosa de mensagens por retry, uma dead-letter queue e serialização por usuário.
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.
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.
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.
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.
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.
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.
exercida em