Decoys, Redundancy, and Why Your API Needs Fallbacks

My power flipped twice before 9 AM today, taking out my router right in the middle of a database migration. If you build software in this country, you already know that "plan A" is rarely the thing that actually runs in production.

Glancing at the news feeds this morning, everyone is obsessed with politicians swapping planes and using decoy vehicles to slip out of airports unnoticed. The news cycle calls it stealth tactics. I just call it dynamic rerouting.

When you strip away the political theater, it’s a lesson in failovers. What happens when your main pipeline gets blocked? Do your applications freeze up, or do they quietly route traffic through the backdoor before the user even notices a spike in latency?

When the Main Route Fails, Where’s Your Decoy?

A lot of backend setups I see locally are terrifyingly optimistic. Developers wire up a single payment gateway or rely on a single third-party verification service, push to production, and hope for the best.

Then Friday evening hits. Transaction volumes surge, the provider's API starts returning 504 Gateway Timeouts, and suddenly your app is dead in the water. Users start yelling on X, customer support gets flooded, and everyone enters crisis mode.

If your architecture doesn't have a built-in secondary route—a silent fallback that picks up the load automatically when the primary endpoint stutters—you're playing a dangerous game. In fintech especially, user trust drops to zero the second a transaction hangs.

We should be engineering our services like those airport escape plans: if the main bird can't clear the runway, the payload should already be moving in the background on an alternative route without alerting the public.

Designing for the Reality of Onitsha and Akure

It’s easy to write clean code when you’re testing locally on localhost with 0ms latency. But out in the field, things get ugly real fast.

A trader sitting at a market stall in Onitsha trying to confirm a transfer isn't working with pristine fiber internet. They’re on a patchy 3G connection that drops packets every three seconds. If your app expects a crisp 200ms round-trip response from the server, it’s going to fail miserably.

We have to adopt a "No gree for anybody" mindset when handling network edge cases:

• Optimistic UI updates: Show the user that action was taken immediately, then reconcile state in the background.
• Persistent local queues: Store transactions locally in SQLite or Hive when offline, then push when connection restores.
• Aggressive exponential backoff: Stop hammering an already dying server every 500 milliseconds. Give it space to recover.

If a developer in Akure testing on a spotty SIM card can’t comfortably use your product, your execution isn't ready for scale yet.

The Sapa of Bad Infrastructure

Reading about Zhu Rongji passing away today reminded me of what it actually takes to modernize legacy infrastructure. The man had to haul a massive, bloated system into the modern global market decades ago. That kind of refactoring is painful, unglamorous, and usually pisses off people who liked the old way.

In our ecosystem, we deal with our own version of infrastructural debt. Legacy core banking integrations, unreliable webhooks, and third-party APIs that feel like they were written during the dial-up era.

Refactoring these touchpoints while keeping the system running is like swapping out an engine while cruising down the highway. It’s stressful, but necessary if you don't want your stack to collapse under its own weight.

At the end of the day, glossy UI designs won't save a product built on fragile logic. Write code that expects things to break, build fallbacks for your fallbacks, and test your app on the worst network connection you can find. That's how we build stuff that actually lasts.