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.
Contexto
Implementei uma mudança no fluxo de limpeza de roles. Ela tratava a associação de uma pessoa como global, embora a pessoa possa ter acesso em vários workspaces.
Problema
Dois usuários perderam acesso entre workspaces e não conseguiam concluir o trabalho. A feature flag conteve o incidente naquele dia, mas não corrigiu a suposição sobre o escopo.
Decisão
Assumi o post-mortem e escrevi a decisão de arquitetura e as regras de negócio. A validação da exclusão deveria ocorrer no serviço dono das permissões; o consumer ficaria responsável por replicar o resultado. Conduzi o épico e sua direção arquitetural. O squad compartilhou a implementação e implantação.
04Acompanhamento
Meses depois, logs de produção revelaram um deadlock diferente no novo consumer. Mensagens sobre a mesma pessoa podiam cair em partições diferentes do Kafka e rodar ao mesmo tempo. Identifiquei a incompatibilidade e contribuí com um advisory lock do PostgreSQL por usuário, retry e dead-letter queue.
Resultado
O consumer substituto entrou em produção em março de 2026. As mudanças de lock e recuperação vieram em junho e julho. Não há medição posterior que permita afirmar uma redução de deadlocks.