Ideia principal

Um gateway de e-mail se troca mudando uma chave de acesso. Um fornecedor de SMS também. Um modelo de linguagem igualmente, desde que a memória durável, o contexto de negócio e as decisões fiquem no produto: esses blocos não guardam nada entre duas chamadas.

Um banco de dados é de outra natureza. Ele carrega o estado durável do sistema. Substituí-lo supõe migrar os dados, garantir a coerência deles, prever a retomada, cuidar dos backups e, às vezes, da replicação.

A substituibilidade, portanto, não é binária, é um gradiente — e o que o gradua não é o valor de negócio do bloco, e sim o estado que ele retém.

Por que isso importa

Dois critérios se sobrepõem e a gente os confunde. O primeiro diz o que temos o direito de ceder — esse bloco carrega o valor? O segundo diz quanto isso vai custar — esse bloco carrega o estado?

Um bloco pode ser perfeitamente indiferente ao núcleo do produto e continuar sendo um dos mais pesados de tornar substituível. É exatamente o caso do banco de dados, e é o que torna esse caso mais difícil que todos os outros.

Nuances e limites

O estado não é a única fonte de custo: uma integração profunda no código, mesmo sem estado, pode tornar uma troca difícil.

E a ausência de estado nunca é completa — um serviço de mensageria guarda históricos, reputações de envio, listas de bloqueio.

Questões em aberto

• Como avaliar de antemão o custo de substituição de um bloco, a não ser substituindo-o?