Stealth Deploys, Earthquakes, and Why Your Failovers Will Fail
Seeing reports of massive earthquakes and wild stealth escapes made me think about fragile tech setups. Here is what happens when production burns and your backup is secretly broken.
My generator killed itself mid-stroke right as I was running a heavy database migration last night. One second Postgres was quietly indexing millions of rows, and the next second the fan in my room died, everything went pitch black, and my local server connection abruptly severed.
That sudden silence is a special kind of dread every builder knows.
Skimming through the news feeds this morning, two stories caught my eye between sips of instant coffee. First was a massive 7.4 earthquake wiping out infrastructure in western Colombia. The second was a bizarre report about Donald Trump sneaking onto a plane tucked inside a catering truck to bypass threats in Turkey.
Strip away the drama, and both stories are fundamentally about the same thing: system fragility and emergency bypasses.
The Hard Reality of Single Points of Failure
When a 7.4 magnitude quake hits physical infrastructure, roads crack and power lines snap. In software, we don't need tectonic plates moving to experience the exact same level of chaos.
Remember the undersea fiber cable cuts that knocked out half of West Africa's internet a while back? One moment your API integration is flying, and the next, your payment webhooks are failing, users are panicking on X, and Sapa is staring you in the face because your checkout flow is completely stalled.
If your tech stack relies entirely on a single AWS region or a single local payment gateway without a automatic fallback, you aren't running a resilient platform. You're running a ticking time bomb.
Building resilient software means assuming the ground beneath your code will shake. It means setting up multi-region database replication, configuring circuit breakers on external HTTP calls, and writing code that degrades gracefully when downstream services choke.
If your third-party SMS service drops dead, does your login screen crash with an unhandled 500 error, or does it silently fall back to WhatsApp OTPs? That's the difference between a amateur setup and a production-grade system.
The "Catering Truck" Deploy Pattern
Reading about someone hiding in a catering cart to slip onto an Air Force jet made me chuckle, mostly because every software developer has pulled off a "catering truck" deploy at 3:00 AM.
You know the scenario. Production is completely down. The standard CI/CD pipeline is taking 20 minutes to run integration tests, automated checks are stuck in queue, and customers are blowing up support.
So what do you do? You bypass the main pipeline. You SSH directly into the EC2 instance, patch the raw JS file with nano, restart pm2, and pray nobody notices how dirty that deployment was.
It gets the job done in an emergency, but here's the catch: dirty hacks leave security backdoors. If you don't go back the next morning to clean up your emergency bypasses, lock down your SSH keys, and commit that hotfix properly into Git, your codebase turns into a maze of forgotten backdoors.
Building "No Gree for Anybody" Architecture
I spent a few months last year working out of a quiet setup in Akure, and one thing I learned from building outside the big tech hubs is that user experience has to be tough. You can't code assuming your user has 5G on an iPhone 15 while sitting in an air-conditioned office.
You're building for the guy riding a keke in Owerri, struggling with a 3G network signal that drops every time he goes under a bridge.
Your frontend shouldn't freeze when an API request takes 8 seconds to resolve. Use optimistic UI updates. Cache aggressive data on the client side using IndexedDB or SQLite. Queue user actions locally and sync them back to your server when the connection restores.
We need to build software with a "No gree for anybody" mindset. Network drops? The app keeps working offline. Database fails over? The read replicas handle the load. API key expires? The system alerts your team on Slack and seamlessly rotates credentials.
Systems break. Power cuts out. The real test of your work isn't how smoothly your code runs when everything is perfect, but how well it holds together when the ground starts shaking under your feet.
Related from Engineering
Let's build your next big product.
Accepting project-based freelance, remote engineering roles, and hybrid positions.