Nota

Fail-open ou fail-closed: o que existe para proteger?

Mantenho dois sistemas com defaults de falha opostos, de propósito. A escolha entre travar e seguir não é dogma: é uma pergunta sobre o que a falha custaria em cada direção.

Quando o contador de gastos de um sistema falha, o que deve acontecer: o sistema trava, ou segue rodando sem contar?

Eu mantenho dois sistemas que respondem em direções opostas. O contraste explica a regra melhor que qualquer princípio abstrato.

O primeiro é um pipeline de conteúdo que roda dentro de uma assinatura. Não há cobrança por unidade, nenhum medidor para estourar. O registro de consumo lá é fail-open: se ele falhar, a execução continua e o buraco fica anotado. Esse registro existe para observar, para eu conseguir responder daqui a uns meses se cada etapa de crítica vale o que custa. Um teto que trava, sobre um gasto que ninguém cobra por unidade, é cerimônia: trava sem proteger nada.

O segundo é o chat deste site. Ele chama uma API cobrada por uso e fica aberto na internet. O teto de gasto diário é fail-closed: contador ausente ou ilegível desliga o chat. A falha barata, um chat fora do ar por algumas horas, protege da falha cara, uma conta correndo enquanto o contador estava quebrado.

A pergunta que decide não é "qual é a boa prática". É: o que existe para proteger, e quanto custa errar para cada lado? Onde há um medidor de verdade, dúvida trava. Onde não há, travar só adiciona atrito.

O detalhe que mais me importa: a assimetria está escrita, nos dois repositórios, um apontando para o outro. Quem conhece um dos sistemas vai estranhar o outro. O registro existe para o estranhamento virar leitura, e não um "conserto" bem-intencionado que desfaz a decisão.