Mohamed KEITA
Note #84 min read

The Hidden Cost of Cloud Computing in Africa

Cloud computing is often presented as the universal solution for scalability, resilience, and modern application development. But this narrative assumes a set of infrastructural conditions that do not hold everywhere. In many African regions, network latency, packet loss, and connectivity instability fundamentally reshape the performance profile of cloud-hosted systems.

This note explores the hidden cost of cloud-first architectures when deployed far from major datacenters. We examine how round-trip latency (RTT), network unreliability, and dependency on distant infrastructure affect commit times, user experience, and overall system robustness — and why local-first or hybrid designs are often more appropriate.

Structural Latency and RTT: Distance Cannot Be Abstracted Away

Cloud regions are geographically concentrated in Europe, North America, and parts of Asia. For many African countries, the physical distance to the nearest hyperscale region creates unavoidable latency.

Approximate RTTs from various African capitals to EU cloud regions:

Abidjan → Paris      90-130 ms
Lagos → Amsterdam   110-150 ms
Nairobi → Frankfurt 120-180 ms
Johannesburg → London 160-220 ms
 

These numbers represent ideal conditions. Under real-world conditions, latency spikes, routing inconsistencies, and congestion often worsen performance.

Every database commit, every API call, every handshake with a cloud service inherits this cost.

Packet Loss and Network Instability

In several regions, packet loss rates between 1% and 5% are not unusual. Even small amounts of loss drastically affect TCP throughput and tail latency.

A simple example:

RTT: 150 ms
→ Effective throughput drops ~50-80%
→ Tail latencies degrade ~2× to 10×
 

Many cloud-first architectures assume:

  • stable connectivity,
  • minimal jitter,
  • low packet loss,
  • reliable failover paths.

In Africa, these assumptions frequently break, producing inconsistent performance even when the cloud backend is technically healthy.

Impact on Commit Latency and Distributed Transactions

Modern applications often depend on database commits, acknowledgments, or state synchronization over the network. When infrastructure is distant, commit latency becomes bounded by RTT.

If a database requires even a single round-trip for commit:

 

On networks with 120-200 ms RTT, a single user request can feel sluggish. For chatty protocols — such as PostgreSQL, MySQL, or certain distributed stores — the problem becomes worse.

More importantly, intermittent disconnections create failure modes where:

  • commits hang,
  • transactions time out,
  • replicas fall behind,
  • caches serve stale data,
  • clients misinterpret transient errors as failures.

This leads to operational fragility: the system becomes “logically reliable” but “physically unreliable.”

Why Cloud-First Architectures Fail in the African Context

The cloud-first model assumes that all clients, services, and data centers have:

  • stable high-bandwidth links,
  • predictable latency,
  • minimal jitter,
  • redundant network routes,
  • consistent power supply.

African connectivity, while improving rapidly, is still characterized by:

  • long-haul submarine dependence,
  • regional transit asymmetry,
  • occasional outages,
  • ISP-level congestion,
  • unstable last-mile infrastructure.

Designs that rely heavily on synchronous access to remote cloud services become brittle.

Common symptoms include:

  • unpredictable latency,
  • slow commits,
  • authentication failures,
  • microservice timeouts,
  • cascading retries,
  • local operations blocked by remote dependencies.

Cloud-first becomes cloud-bottlenecked.

The Cloud as a Single Point of Failure

When all computation and state reside in a remote region, any interruption — even brief — halts the entire system.

A simple dependency chain illustrates the fragility:


Single point of failure
 

If the WAN path drops for 5 seconds, the entire application becomes unusable.

Even edge caching or CDN layers cannot compensate when:

  • transaction validation,
  • authentication,
  • writes,
  • orchestration,
  • or state synchronization

all require cloud connectivity.

Systems become globally centralized and locally fragile.

Conclusion

Cloud computing is powerful — but not universally applicable. In many African environments, the combination of high RTT, packet loss, and unstable network conditions transforms cloud-first architectures into bottlenecks that degrade reliability and user experience.

Local-first, offline-friendly, or hybrid architectures provide better resilience, lower latency, and higher stability. The real lesson is simple: infrastructure must be designed for the environment that uses it, not the environment that built it.

Recommended References

  1. RIPE NCC — Africa Connectivity & Latency Reports
  2. APNIC — Measuring Packet Loss Across Submarine Cables
  3. ACM Queue — The Tail at Scale
  4. Google SRE — Designing Reliable Distributed Systems
  5. Cloudflare Radar — Africa Network Performance