Main idea

An email gateway is replaced by changing an access key. So is an SMS provider. So is a language model, as long as durable memory, business context and decisions stay inside the product: these blocks keep nothing between two calls.

A database is of another nature. It holds the system's durable state. Replacing it means migrating the data, guaranteeing its consistency, planning recovery, handling backups, sometimes replication.

Substitutability is therefore not binary, it is a gradient — and what grades it is not the block's business value, but the state it retains.

Why it matters

Two criteria overlap and get confused. The first says what you are allowed to hand over — does the block carry the value? The second says what it will cost — does the block carry the state?

A block can be entirely indifferent to the heart of the product and still be one of the heaviest to make substitutable. That is exactly the case of the database, and it is what makes that case harder than all the others.

Nuances and limits

State isn't the only source of cost: a deep integration in the code, even stateless, can make a replacement difficult.

And statelessness is never complete — a messaging service keeps histories, sending reputations, block lists.

Open questions

• How do you assess the substitution cost of a block in advance, other than by substituting it?