Real-Time Without a Rebuild

Some requirements look as if they call for a new system and, on closer inspection, call only for a new path through the old one. This story is about one such requirement. It is deliberately kept general — no system, no people involved, no date.

Situation

A system that had grown over many years, running on an older framework version, did what it was built for: it pulled data through external APIs, imported it and displayed it. Then a new requirement arrived — the user interface should update in real time after these imports instead of only on the next page load. The architecture had never been designed for real time.

Initial assumptions

The obvious first thought was that a system never meant for real time would have to be rebuilt for it. Real time felt like a property of the whole — something you don't retrofit into an existing design but plan for from the ground up. Under that assumption, a rebuild seemed like the honest answer.

Problem

A rebuild would have thrown away years of correctly working business logic to serve a single new requirement. It would have been expensive and risky, and it would have put everything else on hold while known functionality was built all over again. The price was out of all proportion to the requirement — it would have meant tearing down an entire house to open a window.

Root cause

On closer inspection, the requirement did not affect the whole system but a single path: how imported data finds its way to the user interface and how the interface learns about a change. The assumption "real time means a new architecture" confused a local need with a global overhaul. The system did not need to be different — only one path through it needed to be rethought.

Decision

Instead of rebuilding, the data flow and the user-interface updates were redesigned in a targeted way — exactly the path from import to display — and everything else was left untouched. The decision was to change the small thing the requirement actually touched, not the big thing it only seemed to touch.

Implementation

The change was deliberately kept narrow. The point at which imported data enters was identified; from there, a path was created that notifies the user interface of changes; and the interface was adapted to accept updates as soon as they arrive. The existing system kept doing what it did — only the update path was new. Small, contained, reversible.

Trade-offs

The retrofitted path is not the most elegant one you would design on a blank sheet for a real-time-native system; it sits alongside older assumptions and carries a little of their legacy with it. That was the deliberate price for meeting the requirement without the cost and risk of a rebuild. We would have decided differently if real time had run through the entire system or if the old architecture had actively fought every change — then a deeper overhaul would have been the more honest answer.

What we learned

A modern requirement rarely demands a modern system. Most "the architecture can't do that" reflexes confuse a local capability with a global rebuild. The useful question is not "was the system built for this?" but "which path actually has to change?" — and that path is almost always far smaller than the system. If you look for the path first instead of condemning the system, you usually find a solution that is orders of magnitude cheaper.

How this changed Batunet

Since then, we meet the sentence "the architecture wasn't built for that" with a smaller question first: which single flow does the requirement touch? This has turned a rebuild from the first reaction into the last option. We check what genuinely has to be new before we declare anything old.

Further reading

• Guide: Legacy Modernization Without a Big Bang — why you evolve what exists in small steps instead of replacing it.
• Playbook: Modernizing a Legacy Monolith — the approach for targeted interventions instead of a rebuild.
• Guide: Software That Still Runs in Ten Years — why changeability determines a system's value over time.
• Decision: The Modular Monolith as a Starting Point — change structure where a problem demands it, not everywhere.

The foundation is the Batunet Engineering Method: decide based on the properties of the problem, build in small, reversible steps.

Before declaring a system incapable, it pays to ask the smaller question: which single path through it actually has to change? It is almost always shorter than the path to a rebuild.