Building Software That Survives Power Cuts: Lessons from Kathmandu

Where 'five nines' meets the real world

Much of the software industry designs for an imaginary world of stable power, fast networks, and users who retry politely. Build a banking kiosk for a branch in Kathmandu or an access turnstile for a gym during load-shedding season and that world evaporates. The machine must do the right thing when the power dies mid-transaction, when the network drops mid-sync, and when both come back in the wrong order.

Here's what building for that reality taught us lessons we now apply to every system, everywhere, because networks fail in Texas too.

Lesson 1: Every operation is a transaction

When a customer feeds cash into a kiosk, there is no acceptable version of 'the request failed, please try again.' The money is physically inside the machine. We design every such operation as an atomic, journaled transaction: the device records what it has accepted locally, durably, before any network call and reconciliation replays the journal until the core system confirms every rupee.

The generalized rule: identify the operations in your system where retry is not an option, and give them a durable local journal. You'll find more of them than you expect.

Lesson 2: Offline is a state, not an error

Our gym access system validates memberships locally at the turnstile and syncs when connectivity returns. Members never notice a network outage which is the point. Systems that treat 'offline' as an exception path get exception-quality code there; systems that treat it as a first-class state get tested, reliable behavior.

Ask of every feature: what should this do with no network? 'Show an error' is sometimes the right answer but it should be a decision, not a default.

Lesson 3: Recovery order matters more than uptime

Power cuts end. What separates robust systems is what happens next: services that come back in the wrong order, queues that replay duplicates, clocks that drifted. We test recovery sequences explicitly kill the power mid-write in staging, on purpose, and watch what happens. The first time we did this, we found four bugs in an afternoon.

Lesson 4: Resilience is cheaper up front

None of this is expensive if it's designed in from the start a journal table, an idempotency key, a sync queue. Retrofitted after an incident, each becomes a migration project. The best time to buy insurance is before the fire.

The transferable insight

Building in Nepal forces you to confront failure modes that better infrastructure lets you postpone but never actually removes. The AWS region outage, the fiber cut, the DDoS: they're load-shedding by another name. Software built where resilience isn't optional turns out to be exactly the software you want everywhere.