Sinking Car Syndrome: When Bad Architecture Is Terminal

Sinking Car Syndrome occurs when an architecture is so fundamentally flawed that incremental fixes only delay inevitable failure rather than resolve it. No amount of optimization rescues a system built on the wrong foundation, just as no engineering improvement makes a car suitable for crossing the Atlantic. Recognition of terminal architecture requires abandoning sunk cost thinking and redesigning from first principles.

There are two types of post incident review in technology. The first is genuinely useful, since you learn something, fix something, and sleep better afterward. The second is an elaborate ritual in which intelligent adults spend considerable time and money working out why a car sank, before commissioning a study on how to make the next one sink slightly less.

This piece is about the second type.

1. The Road Trip From London To New York

Imagine you need to get from London to New York. It’s a simple goal, except you’ve decided to go by car. Before dismissing this as insane, consider the business case, because there is one, and it was almost certainly written by a committee.

1. Cars are “tried and tested,” while planes crash, and there’s a slide deck about that.
2. There are existing supplier relationships with several car manufacturers, and the volume discounts are exceptional.
3. The person who made the final call really, really likes cars.
4. The support team knows cars, and retraining them on boats would take quarters.
5. Execution needs to start tomorrow, a car is available today, and alignment has been achieved.

So off everyone goes. The hatchback makes it about three metres off the coast of Scotland before becoming a submarine, which the team logs as progress. Undeterred, they send a truck, reasoning that trucks are more durable, famously. It manages two metres, which is technically worse, but that gets attributed to a suboptimal angle of entry and filed away as a learning. Then comes the Porsche, with a bigger run up and considerably more conviction, reaching four metres, which gets celebrated internally as a full improvement on the hatchback. There is data now, and the data gets analysed, and a dashboard gets built, and a retrospective gets held to talk through what it all means.

2. Six Months Later: The Land Bridge Strategy

Half a year in, the team has logged twelve metres of progress, and the sunken cars are starting to form a rudimentary land bridge, which someone in leadership describes, apparently without irony, as emergent infrastructure. Two hundred million dollars have been committed by this point, and the sunk costs have been sunk both literally and financially. Pivoting now would mean admitting that the original decision was wrong, and nobody in the room wants to be the one who says it, because the person who made the original decision is still in the room, and still likes cars.

So the team brainstorms optimisations such as winding the windows up tighter before entry, applying extra underseal to improve aquatic durability, experimenting with tyre pressure since overinflation shows theoretical promise, or simply procuring more cars and sinking them faster. Some of these ideas will even show marginal gains, but none of them will result in reaching New York, because the underlying choice of car over boat was wrong from the start. It isn’t possible to iterate your way out of a categorically wrong architecture. It is only possible to make the failure slower and considerably more expensive.

3. The Actual Problem

Having sat in enough of these reviews, I recognise the pattern outside the metaphor too, in the ageing core banking platform patched for a decade past its design life, in the on premises data warehouse rearchitected three times because migrating it properly was always next quarter’s problem, and in the monolith that apparently just needs one more service extracted, for the fourth year running.

I’m usually brought in to find the root cause, suggest a fix, and restore confidence. More often than people want to hear, the root cause turns out to be the architecture itself. The system was never going to work as designed, not because the engineers were bad or the implementation careless, but because someone made a foundational technology choice that was wrong, and rather than confront that, the organisation built an increasingly elaborate structure around it instead. Past that point, no amount of tuning, patching, right sizing, or retrospective documentation changes the trajectory, because the work at that stage isn’t fixing a broken car so much as researching why cars sink.

4. How Do You Know The Architecture Is Terminal

The obvious objection to all this is that most systems people call unfixable are not actually terminal. Plenty of old, ugly, or badly designed systems can be rehabilitated a piece at a time, and technical debt is a useful concept precisely because it can often be repaid rather than written off. A slow query is not terminal architecture. A badly indexed database is not terminal architecture. An ageing programming language is not terminal architecture. Even a monolith, on its own, is not terminal architecture. Most of what looks unfixable is actually addressable once you find the right seam and replace one capability at a time.

An architecture becomes terminal only when an essential requirement conflicts with something fundamental about how the system was built, so that meeting the requirement means changing the architecture itself rather than improving how it was implemented. Five signs tend to show up together when that has happened.

1. The same underlying limitation keeps showing up behind different incidents, wearing a different symptom each time.
2. Every fix moves the bottleneck instead of removing it, so improving database capacity exposes locking, fixing locking exposes synchronous coupling, and adding retries creates retry storms somewhere else.
3. Cost keeps rising much faster than capability, so that going from 99.9 percent reliability to 99.99 percent, or doubling throughput, or halving latency, requires a wildly disproportionate amount of new infrastructure and complexity.
4. A real business requirement contradicts a basic design assumption, such as needing independent deployment on a system with tightly coupled shared state, needing regional isolation on a system with unavoidable global state, or needing millisecond response times on a transaction that has to cross several synchronous systems in sequence.
5. The proposed fixes increasingly amount to building a boat around the car, until so much compensating architecture surrounds the original system that keeping it is more complicated than replacing what it was meant to do in the first place.

When several of these show up around the same system at the same time, the architecture itself is usually the actual problem, not the implementation sitting on top of it.

5. What To Do Instead

The honest conversation, which actually costs less in the long run, sounds something like this. This architecture is terminal, it will never reliably do what we need it to do, so let’s stop optimising it and decide what we’re transitioning to instead. Three questions follow from there: how fast can the organisation pivot, what does the migration path look like, and what gets salvaged versus written off.

It helps to separate the destination from the journey here. The target architecture can and should be designed from first principles, without compromising for whatever exists today, but the migration itself rarely needs to be one single rewrite. Big bang replacements of serious systems have a poor track record, mostly because nobody fully understands everything the old system actually does until they try replacing it all at once. It is usually safer to grow the new system around the edges of the old one, a pattern engineers sometimes call a strangler migration, moving capabilities across one at a time until nothing of the original remains and it can simply be switched off. Be radical about the destination and incremental about the migration.

These are harder conversations than root cause analysis, because someone has to say that a past decision was wrong. But they are the right conversations, and the longer they get delayed, the more sunken cars end up getting funded in the meantime.

The goal was never New York by car. The goal was New York. Get a boat.