Catering Trucks, Circuit Breakers, and Building for the Worst-Case Scenario

There is a strange, chaotic beauty in watching a former U.S. President abandon a high-tech presidential jet to sneak across a runway in an airport catering truck just to avoid getting targeted. It looks ridiculous on camera. It breaks every protocol of luxury and prestige. But it achieves the exact objective: keeping the payload alive when the main pipe is compromised.

In software engineering, we call that a dirty failover. And honestly, more devs need to embrace it.

The Dirty Failover Pattern

Too many developers build software assuming the main road will always be clear. They set up their sleek microservices, point everything at a primary database, hook up a single payment gateway, and call it a day.

Then reality hits. AWS us-east-1 drops off the face of the earth. Or locally, your primary SMS gateway suddenly starts swallowing OTPs because a fiber optic cable got severed somewhere in Lagos mainland.

If your system doesn't have a "catering truck"—a stripped-down, zero-ego fallback route—you're dead in the water.

Last year, while hacking together a logistics tool for vendors down in Onitsha, I learned this the hard way. The network down there during peak market hours doesn't just slow down; it degrades into absolute static. If my app waited for a full round-trip HTTP response from a cloud database before showing a order confirmation, the sellers would simply close the tab and use paper. We had to rewrite the entire sync mechanism to hit local IndexedDB first, push to a background worker, and route through an alternative low-bandwidth SMS relay whenever TCP socket connection failed. It wasn't pretty, but it kept transactions moving.

When Infrastructure Completely Crumbles

Looking at the news coming out of Colombia today after that 6.0+ magnitude earthquake hits home differently when you build tech in emerging markets. When physical infrastructure drops, digital infrastructure goes with it.

We don't even need natural disasters to feel this in Nigeria. Anyone who has tried to ship code during a rainy morning in Jos, or debugged an API endpoint in a Gbagada workstation while the generator trips every twenty minutes, knows that reliability is an illusion.

If you are building for users who operate in unpredictable environments, offline-first isn't a luxury feature. It's the whole product.

• State caching over fresh fetches: Stop making your mobile UI depend on a live API call just to render basic user profiles.
• Graceful degradation: If your vector search or AI recommendation engine crashes, drop back to simple Postgres full-text search. Don't throw a 500 server error page at the user.
• Circuit breakers: Use libraries like Cockatiel or Opossum in your Node backend. If a third-party service fails three times in a row, stop hammering it. Redirect traffic to a secondary queue immediately.

Stop Coding for the Happy Path

We spend way too much time obsessing over pristine code architecture, clean patterns, and elegant abstractions. But users don't care if your dependency injection setup is textbook clean when your application is stuck on a infinite loading spinner.

They care if the operation completes. They care if the money goes through, if the data gets saved, and if the app responds when the network drops to 2G.

"No gree for anybody" shouldn't just be a popular slang; it should be how you write your retry logic. Expect the primary database connection pool to fill up. Expect your payment partner to go offline at midnight. Expect the fiber line to get cut.

Build the ugly fallback. Build the secret route through the catering truck. Because when things inevitably break down, nobody cares how you got the data from A to B—only that it arrived.