Most software is written on hardware that never loses power unexpectedly. Deployed into an environment where it does, the same code produces corrupted files, half-written records and devices that come back up in states the developer never considered.
Assume the process can stop between any two instructions
That is the whole discipline. Every operation that matters should be either complete or absent after a restart, never half-applied. In practice this means write-ahead patterns, atomic file replacement rather than in-place edits, and transactions that cover the full unit of work rather than the convenient part of it.
Buffer with intent
- Queue outbound data locally and drain it when connectivity and power allow.
- Bound the buffer. An unbounded queue turns a two-day outage into a full disk and a second failure.
- Decide explicitly what to drop first when the bound is reached, rather than discovering it in production.
Make recovery observable
A device that silently loses four hours of readings looks identical to one that recorded nothing because nothing happened. Record the gap. Systems that report what they missed are far easier to trust than systems that quietly present incomplete data as complete.