The Region That Shouldn't Exist

Editor’s note:Infrastructure decisions that change who gets to participate in the modern internet rarely make headlines. This one should. The engineers who built this region didn't wait for permission. They collected data and showed their work.

It started as a weekend experiment. In August 2024, a small infrastructure team at a B2B SaaS company decided to test a hypothesis: that their API response times for users in West Africa were bad enough that a significant fraction of those users were experiencing the product as something fundamentally different from what users in North America and Europe were experiencing.

The hypothesis was correct. Their closest production region was in Frankfurt. For a user in Lagos, a synchronous API call that took 35 milliseconds in Amsterdam was taking between 380 and 430 milliseconds. Not because of poor code, but because of physics. The packet had to cross an ocean twice.

"We knew it was bad," says the engineer who ran the initial latency study, who asked to be identified only as Simi. "We did not know it was that bad. There is a difference between 'some users have higher latency' and 'some users are using a fundamentally slower application because of where they live.'"

The weekend experiment involved spinning up a minimal set of AWS services (an ALB, a read replica of their primary database, a handful of Lambda functions, and a CloudFront distribution) in the af-south-1 region in Cape Town. Cape Town is not Lagos, but at 3,800 kilometers it is substantially closer than Frankfurt at 5,200. The latency for the experiment improved to approximately 95 milliseconds. Not perfect, but a different product than 400.

The problem was that Simi and her two colleagues had done this without formal approval. They had used resources charged to a cost center that was not theirs. They had made architectural decisions that would require significant engineering work to productionize properly. They had, in the vocabulary of most enterprise infrastructure teams, built shadow IT.

"We were very aware of that," she says. "We also had data. And data is the thing that makes shadow IT into a proposal."

The data landed. Within six weeks of the experiment, the company had approved a formal project to build out a production presence in af-south-1, with a proper architecture review, a budget, and a rollout plan. Simi was named technical lead. The region went live seven months later.

It now serves approximately 340,000 monthly active users across fifteen countries in West and Central Africa. Response times for those users average 88 milliseconds. The business impact (retention, expansion revenue, support ticket volume) has been significant enough that the company is evaluating a second African region.

The story is not unusual. It is, increasingly, how cloud infrastructure decisions actually get made: not from the top down, as providers and enterprises plan expansion, but from experiments run by engineers who are paying attention to who their users are and where they live. The regions that matter most are often the ones nobody planned.

The region wasn't supposed to become production. But the latency numbers were too good to ignore, and one morning a user in Lagos hit our API and waited 40 milliseconds instead of 400.