Johannesburg, Cape Town or Nairobi? Choosing a Region for Low Latency

A common mistake is to assume the nearest city is the fastest region. In Africa, routing often matters more than raw distance. Traffic between two neighbouring countries can still hairpin through Europe if the peering is not there, adding 150ms for no good reason.

So the real question is not "where are my users" but "how does packet actually travel from my users to my servers today". Measure before you commit.

Measure the real path, not the map

Run a handful of tests from the networks your customers actually use, mobile and fibre, in each target market. A quick loop against candidate regions tells you more than any marketing page.

for host in jhb.digitel.africa cpt.digitel.africa nbo.digitel.africa; do
  echo "== $host =="
  ping -c 20 $host | tail -1
  mtr --report --report-cycles 30 $host | tail -5
done

A rule of thumb that holds up

• Serving mostly South African users? Johannesburg first, it has the deepest peering at NAPAfrica.
• West or East African audience? Test a local edge, but keep the database where the writes are cheapest and best-connected.
• Pan-African SaaS? Put static assets and caching on the edge, keep one primary database region, and add read replicas only when the numbers justify it.

Users feel the round trip, not the region label. Two hundred milliseconds saved on the login call is worth more than any datasheet.

Once you have picked a home region, put a CDN in front of everything cacheable so distant users still get fast first bytes. Our hosting and cloud platform both peer directly at NAPAfrica, which is usually the single biggest latency win for South African traffic.

Re-measure every quarter. Peering relationships and subsea cables change, and a region that was second-best last year may be the obvious choice today.