International architecture guidance assumes the power stays on. South African delivery teams know better: branches lose power on schedule, mobile towers on battery degrade data coverage, and 'the system is down' often means 'the building is down'. Resilience here is not exotic engineering — it is choosing patterns that expect interruption.
Three patterns that matter most
Queue-and-sync at the edge. Field and branch applications should treat connectivity as intermittent by default: capture locally, queue outbound work, reconcile on reconnect with deterministic conflict rules. The difference between a mobile app that queues and one that spins is the difference between a non-event and a support ticket storm.
Degrade by feature, not by system. When a dependency disappears, drop the affected capability and keep the rest: read-only mode beats an error page; cached prices beat no prices. This has to be designed — systems only degrade gracefully on purpose.
Fail over the connectivity, not just the servers. Cloud workloads survive load-shedding; your users' access to them is the fragile part. Dual-provider links at key sites and mobile fallback in apps address the real failure mode.
Test it like you mean it
A resilience design that has never been exercised is a hope, not a capability. Pull the plug in staging: kill the link mid-transaction, restore it, and verify nothing was lost or doubled. We run these drills before go-live on every system where downtime costs money — which, in this country, is all of them.