Vários sistemas que precisam de funcionar em conjunto, mesmo quando um deles falha.

Porque a primeira recomendação que damos muitas vezes é não separar. Cada novo serviço é um novo modo de falha, e os modos de falha multiplicam-se mais depressa do que as funcionalidades. Um exemplo dos nossos próprios sistemas: o backend de um deles é um único ficheiro de 9.516 linhas com 99 rotas. Não é elegante e dizemo-lo, mas é publicado numa só etapa e depurado num só lugar. A separação faz-se quando existe um motivo mensurável — um serviço que tem de escalar separadamente, uma equipa separada, um ritmo de entrega separado.

Depende do que decidimos em conjunto na fase de mapeamento, e é essa a ideia. Nos nossos sistemas: a mensagem entra na fila e é reenviada um número limitado de vezes, depois chega à troca de cartas mortas, onde pode ser vista; a integração instável tem um interruptor que, após dez falhas consecutivas, pára durante dois minutos em vez de manter os pedidos em espera; e as ações que custam dinheiro são bloqueadas por uma gate que, em exceção, recusa, não permite.

Com uma chave de idempotência, não com uma verificação “já vi isto?” que tem race condition. Concretamente: inserimos uma linha com o identificador do evento e, se a base de dados recusar por violação de unicidade, tratamos esse código de erro como sinal de duplicado, não como falha. Para pagamentos, o marcador fica na transação de crédito, por isso o reenvio do mesmo webhook não credita duas vezes.

Ambos, e a escolha é justificada sempre. Um sistema corre em contentor, mas sem volumes montados, o que significa que a publicação é uma cópia para o contentor mais reinício — um `docker rm` ali perde o estado, e isso está escrito no documento de operação exatamente assim. Outra plataforma não tem qualquer Docker: a publicação é sincronização de ficheiros, e os scripts de publicação são instalados manualmente com privilégios de administrador e expostos ao fluxo automático por exatamente dois caminhos permitidos. O motivo está escrito no código: um script que o fluxo pode reescrever é um script pelo qual o fluxo pode escalar.

Por experiência negativa. Um relatório diário nosso esteve morto durante onze dias, entre 7 e 17 de agosto, enquanto a tarefa agendada era acionada todos os dias — o comando usado saía em silêncio em caso de erro e não escrevia nada. Desde então, cada tarefa corre num invólucro que percorre a resposta por listas de falhas, trata “200 com falhas” como resultado distinto, tem tempo máximo de execução e escreve uma linha estruturada por execução. Os alertas têm limiar de repetição, e o marcador é removido na primeira reússita.

Muito, se o fornecedor estiver numa área que se move depressa. Para voz temos três pontes separadas — uma para cada fornecedor de fala em tempo real — que implementam a mesma interface. A ponte faz a conversão de áudio entre a central telefónica e o fornecedor, numa porta dedicada, com o servidor de saúde ligado apenas à interface local, não exposta. A mudança de fornecedor torna-se uma decisão, não uma reescrita.

Não em todo o lado, e preferimos dizer onde. Na preparação desta página medimos dois sistemas e encontrámos o documento próprio em atraso: uma afirmação sobre o tamanho de um ficheiro estava cerca de 16% abaixo da realidade, e um diagrama de infraestrutura descrevia um servidor de onde já tínhamos mudado. A regra que aplicamos e que pedimos nos projetos: quando o documento e a medição não concordam, a medição tem razão, e o documento é corrigido no mesmo passo.

Não prometemos objetivos de disponibilidade sem medição — uma percentagem do tipo “99,9%” exige dados de terreno ao longo de um período, e onde não os temos não os afirmamos. Não projetamos sistemas que não possamos operar ou entregar: se o resultado é uma arquitetura que a vossa equipa não consegue manter, é uma arquitetura errada. E não fazemos certificações de conformidade — podemos construir os controlos, não podemos emitir o certificado.