Most embedded systems literature quietly assumes the wall socket is a battery with infinite capacity. Power interruptions appear in the appendix, somewhere between "ESD considerations" and "conformal coating," as rare events to be survived.

In Lilongwe, the grid schedules its own failures. ESCOM publishes load-shedding timetables the way other utilities publish maintenance windows. Four to eight hours without mains, most days, is not a fault condition. It is Tuesday.

If you design electronics for this environment the way the textbooks assume, you ship things that corrupt their flash weekly. Designing for intermittency instead of around it turns out to change almost every layer of the stack.

Assume you are always about to lose power

The first mental shift: there is no such thing as a safe long-running operation. Every write, every state transition, every over-the-air update must be structured so that power loss at any instant leaves the system recoverable.

In practice this means:

  • Journaled or double-buffered persistence. Never overwrite the only good copy of anything. Write the new record, verify it, then retire the old one.
  • Idempotent boot. The device will boot thousands of times in its life, often mid-operation. Boot must be a safe place to land from anywhere.
  • Brownout detection you actually use. The ESP32's brownout detector is usually treated as a nuisance reset source. Wired to an interrupt with a few hundred microfarads of holdup capacitance, it becomes a "finish your sentence" warning — enough time to close a file cleanly.
// Holdup capacitor sized for one clean shutdown:
// C = (I_load × t_shutdown) / (V_nominal - V_min)
// 150 mA × 20 ms / (3.3 V − 2.8 V) ≈ 6,000 µF

That capacitor bank costs more than the microcontroller. It is worth it.

The battery is not backup — it is the system

Once outages are routine, the architecture inverts: mains power becomes the charging opportunity, and the battery becomes the true power source. This sounds like a semantic game until you try to size things.

A "backup" battery gets sized for the rare bad day. A primary battery gets sized for the duty cycle — and suddenly you care enormously about sleep currents, radio schedules, and whether that always-on status LED is really necessary (it draws more than the sleeping CPU by two orders of magnitude).

Networks fail with the power

The subtle second-order effect: when the grid fails in a neighborhood, everything fails together. The cell tower's own batteries last a few hours, then your beautifully power-resilient device is awake, healthy, and shouting into a dead network.

So queuing is not an optimization; it is the primary transport. The device's real job is to append observations to durable local storage, and opportunistically drain that queue when both power and network happen to coexist. Designs that treat "send reading" as the atomic unit fail here. Designs that treat "record reading" as atomic and "sync" as a background hobby survive.

Constraints are a gift, mostly

It is tempting to romanticize this: constraints breed creativity, and so on. The honest version is that designing for intermittency is slower, costs BOM money, and produces systems that look overbuilt to reviewers from stable-grid countries.

But those systems also survive contact with the real world far beyond Malawi. Power fails everywhere — at trailheads, in disaster zones, in that server closet with the overloaded UPS. Hardware designed where failure is routine turns out to be hardware that works, period.

The grid being unreliable taught me more about engineering than any stable bench supply ever did.