As doze perguntas que faço em toda revisão de arquitetura

Depois de revisões de arquitetura suficientes, você para de improvisar. Os sistemas mudam; as perguntas não. Estas são as doze que faço em toda revisão, na ordem em que faço, e mais ou menos como é uma resposta ruim. Não são espertas. Funcionam porque são feitas toda vez, em todo sistema, sem exceção para sistemas que parecem bem.

As perguntas

• Qual é a única operação para a qual este sistema existe, e você consegue me mostrar o caminho dela de ponta a ponta?
• Onde o dinheiro, ou a coisa que faz as vezes de dinheiro, muda de mãos, e o que torna essa etapa atômica?
• O que acontece quando o banco fica indisponível por trinta segundos?
• O que acontece quando a mesma requisição chega duas vezes?
• Qual dado está duplicado em dois armazenamentos, e o que mantém as cópias alinhadas?
• Qual componente você teria mais medo de colocar em produção numa sexta-feira, e por quê?
• Como uma requisição é autenticada, e onde essa decisão é imposta além da borda?
• Mostre os últimos três incidentes. O que cada um ensinou, e o que mudou?
• Se eu excluir um cliente, o que sobra?
• Qual é a dependência mais antiga em produção, e quem é dono de atualizá-la?
• Qual decisão aqui seria a mais cara de reverter, e ela foi tomada de propósito?
• Quem consegue explicar o sistema sem a pessoa que o construiu na sala?

Por que essas doze

A primeira pergunta calibra todo o resto. Se o time não consegue traçar o caminho principal sem abrir cinco repositórios e uma wiki, o sistema já é mais complexo do que seus donos conseguem guardar na cabeça, e toda outra resposta será parcial.

As perguntas dois a cinco são sobre correção sob estresse. São as que encontram as falhas que ninguém mais encontra, porque perguntam sobre as fronteiras: a transação que atravessa serviços, o retry que cria um pedido duplicado, o cache que é desatualizado por design mas ninguém escreveu por quanto tempo. Uma resposta confiante é boa. 'Acho que isso é tratado' é onde começo a ler código.

A pergunta seis é um atalho. Engenheiros sempre sabem qual componente é frágil. Raramente são perguntados. A resposta costuma nomear o lugar de onde virá o próximo incidente, e é de graça.

A sete é sobre defesa em profundidade. Um sistema que verifica permissões só no gateway tem uma fechadura na porta da frente e todos os cômodos internos abertos. Qualquer chamada interna, script ou rota mal configurada passa por fora.

A oito é sobre aprendizado. Três incidentes com três mudanças duradouras é um sistema saudável. Três incidentes com 'a gente reiniciou' é um sistema que vai ter o mesmo incidente uma quarta vez.

Da nove à onze é sobre o futuro. A exclusão revela o que possui o quê. A dependência mais antiga revela como a manutenção funciona de verdade. A decisão cara de reverter revela se a arquitetura foi escolhida ou acumulada.

A doze é sobre o fator ônibus, e é a que mais frequentemente muda minha recomendação. Uma arquitetura sólida que mora na cabeça de uma pessoa é um risco, não um ativo.

Como uso as respostas

Não dou nota. Anoto cada resposta, incluindo as pausas, e marco quais foram confiantes, quais foram incertas e quais estavam erradas. As respostas erradas, aquelas em que o time disse 'isso é tratado' e o código diz outra coisa, são o resultado mais valioso da revisão, porque mostram onde o modelo que o time tem do sistema e o sistema em si divergiram.

Depois priorizo por raio de explosão, não por elegância. Um cache desatualizado num dashboard de relatórios é uma nota. Um endpoint de pagamento não idempotente é o primeiro item, em negrito, com data.

O que eu não pergunto

Não pergunto qual framework usam, se é microsserviços ou monólito, nem como é o diagrama. Essas são respostas a perguntas que ninguém fez. Já vi diagramas lindos de sistemas que não sobreviveriam a trinta segundos de banco fora do ar, e monólitos feios que respondiam bem a cada uma dessas perguntas.

A lista é sua. Faça as doze, em ordem, no seu próprio sistema, e anote onde você hesitou. Essa hesitação é a revisão.