Sacrificial Architecture
Design knowing you may throw the system away, and treat that as a sign of success.
“But often the best code you can write now is code you'll discard in a couple of years time.”
To an executive
A first version that is later replaced is not a failure. It often means the product succeeded and outgrew its beginnings, so plan for the rebuild rather than fear it.
To an engineer
Decide how long a system should live and write it down. Optimise early for learning and speed, and keep parts modular so they can be replaced without a full rewrite.
The idea
Fowler points out that many successful systems replaced their early architectures as they grew. eBay, for example, began as Perl scripts, was rewritten in C++, and later rewritten again in Java. The first architecture was right for its time and was deliberately sacrificed. Often the best code you can write now is code you will discard in a couple of years.
Accepting that code has a shelf life changes how you invest: optimise for learning and speed early, and build modularity so parts can be replaced without replacing everything.
Why it works
Systems outgrow their architectures. A design that fits a thousand users may not fit a million. Under fast growth, replacement is a normal consequence of success.
Early priorities differ from later ones. At the start, the flexibility to change features matters more than performance or availability. A sacrificial design lets you optimise for what matters now.
Saying it upfront removes the stigma. If everyone knows the system is built to be replaced, the rewrite is a planned step rather than an admission of failure.
The first version teaches the right structure. Building and running it shows where the module boundaries should be, which the replacement can then use.
Where it applies
- New products and markets, where demand is unproven.
- Experiments and pilots, built to answer a question.
- Features released to a subset of users for feedback before being built properly.
- Fast-growing systems, where you expect to outgrow today's design.
How to apply
- State the expected lifespan and the trigger for replacement, for example in an ADR.
- Keep internal quality reasonable. Sacrificial does not mean sloppy; poor code hurts long before the replacement date.
- Draw clear module boundaries, so you can sacrifice parts rather than the whole.
- Prefer simple structures for the first version; a monolith is usually a better sacrifice than a distributed system.
- Watch for organisational blockers, such as accounting rules that make replacing an asset look like a loss.
Example scenario
A team built a quick product for a new market and documented it in an ADR as sacrificial, with an expected life of about 12 months and a replacement trigger tied to customer numbers.
When demand was validated, they rebuilt the core properly, reusing the module boundaries the first version had revealed. Because the plan had been agreed at the start, the rewrite went ahead without the sunk-cost arguments that usually block one.
Questions to ask
- How long do we honestly expect this system to live, and have we written that down?
- What would make us replace it, and would that count as success?
- Which parts are built to last, and which are built to be sacrificed?
When not to use it
- Systems that clearly need to last decades, such as core ledgers or regulated records, where replacement is costly and rare.
- When nobody will fund the replacement, in which case "sacrificial" code simply becomes permanent.
How it misleads you
Using sacrifice to excuse sloppy work in systems that will clearly live for decades. Fowler is explicit that sacrificing internal quality is a mistake even in a system you plan to replace. And a system labelled temporary often outlives everyone's plans; if the replacement never comes, you are left with the shortcuts.
In the wild
Further reading
Last reviewed · Suggest an improvement