Designing for what you can't know

Most systems are built for the happy path and then patched for failures. I have come to prefer the opposite: decide early what the product should do when it cannot know something, because that is often when people need it most.

The situation

Invictus shows live prices and positions from seven blockchains. Blockchains occasionally stop producing new data, for seconds or sometimes much longer. Before designing anything, we looked at how often this had actually happened on the chains we support. It was not rare.

The tempting answer

The usual instinct when a data source goes quiet is to switch to a backup source and keep the numbers moving. That is right when one provider has a problem. But when the whole chain has paused, every source returns the same old data. Switching would keep the screen looking alive while showing information that is no longer true.

What we did instead

We separated the two cases. If one provider falls behind while others keep moving, the system switches providers. If every independent source agrees nothing has changed for a while, the chain itself has paused, and the product says so:

• It keeps showing the last price, clearly labelled "chain halted since", with the time.
• It does not accept new transactions on that chain until it resumes.
• Anything already in progress waits, and its time limits pause too, so nothing fails just because the chain did.
• When data resumes, everything picks up from where it stopped.

The trade-off we accepted

A very quiet chain can look paused for a few seconds even when it is fine. We decided a short, honest label was better than adding complicated special cases to hide it.

The same thinking applies far beyond crypto: a delivery app that says "location last updated 5 minutes ago" earns more trust than one that shows a confident dot in the wrong place.