Why We Build on the Edge: Cloudflare Workers for African Applications

The default infrastructure stack for web applications is a server in a US data centre, served globally. This made sense when internet infrastructure was concentrated in the US and Europe, because that was where the servers, the CDNs, and the connectivity were.

Nigerian internet infrastructure has changed substantially. Cloudflare, AWS, Google Cloud, and Azure now operate Points of Presence (PoPs) in Lagos, Johannesburg, Nairobi, and several other African cities. The latency assumptions built into the "US-East is fine for everyone" default no longer hold — but most applications are still deployed as if they do.

The consequence: Nigerian users pay a performance tax that their counterparts in London or New York do not.

The Physics of Latency

A network round trip from a browser in Lagos to a server in US-East-1 (Northern Virginia) and back covers approximately 18,000 km. Light travels through fibre at roughly 200,000 km/s, giving a theoretical floor of 90ms. In practice, routing through submarine cables, terrestrial backhaul, and multiple network hops produces a real-world latency of 150–250ms for a typical request.

A request to a server in Lagos or to a Cloudflare PoP terminating locally takes 15–40ms.

The difference — 120–200ms per request — compounds across every asset, API call, and page navigation in your application. For a page with twenty requests (HTML, CSS, JavaScript, API calls, images), the accumulated latency difference between a Nigerian-proximate server and US-East can exceed two seconds.

This is not a theoretical performance metric. It is checkout abandonment, form abandonment, and session drop-off. Research published by Google and Akamai consistently shows a 1-second latency increase corresponds to a 7–11% reduction in conversion rates. For Nigerian businesses operating web applications, the infrastructure choice is a revenue decision.

What Cloudflare Workers Is

Cloudflare Workers is a serverless execution environment that runs JavaScript (and via WASM, other languages) on Cloudflare's global edge network — including their African PoPs. When a user in Lagos requests a Workers application, the code runs in Cloudflare's Lagos PoP rather than routing to a distant origin server.

The technology is V8 isolates rather than containers — lightweight, fast-starting execution contexts that start in under a millisecond versus the hundreds of milliseconds that container cold starts require. Workers is designed for high-frequency, low-latency request handling.

This is the infrastructure our applications run on. The practical implication is that most request handling — authentication checks, data fetching, response rendering — happens 200ms closer to the user than it would on a US-East server.

What Edge Computing Changes for Each Application Layer

Static and ISR Content

Static content (HTML, CSS, JavaScript bundles, images) belongs on a CDN regardless of compute strategy. Cloudflare's CDN caches static assets in every PoP, so a static file requested from Lagos is served from Lagos. This is table-stakes performance; most applications already benefit from CDN for static assets.

Incremental Static Regeneration (ISR) — where pages are pre-rendered but regenerated on a schedule — works on Workers via the @opennextjs/cloudflare adapter. A content page that changes infrequently (a product page, a blog post, a service description) is served as a cached edge response with near-zero computation time. The first request after a cache miss triggers regeneration; subsequent requests hit the cache until TTL expires.

Server-Side Rendering

SSR requests — pages that must be rendered server-side with user-specific data — are where edge computing makes the largest visible difference for Nigerian users. The Workers runtime handles the render at the edge, queries the appropriate data source, and returns the completed HTML. For applications using Cloudflare D1 (the SQLite-backed edge database) as their data layer, the database query and the render both happen at the edge with no round-trip to a distant origin.

For applications that need a remote database (PostgreSQL, MySQL), the edge render still happens locally but must make a back-end call to the database. In this architecture, the edge handles request authentication, caching, and response assembly; only the database call reaches out to the origin region. The user-facing latency reduction is the time saved on authentication and rendering, which is typically 30–60ms.

API Routes and Backend Functions

Edge-deployed API routes serve authentication endpoints, webhook processing, and lightweight data operations at latency competitive with locally-hosted VMs. For Nigerian applications where a user authenticates on page load, the difference between a US-East authentication endpoint and an edge endpoint is noticeable: login feels instant rather than sluggish.

For compute-heavy operations — PDF generation, image processing, ML inference, complex database joins — Workers is not the right runtime. These operations belong on an origin server where compute is abundant and latency to the compute is not user-facing. The architectural pattern is: edge handles ingestion and routing, origin handles heavy processing, edge handles response delivery.

Real-Time Features

Cloudflare Durable Objects provide stateful coordination at the edge — the infrastructure for real-time features like collaborative editing, live presence, and websocket connections that require consistent state across multiple connections. This is a more specialised use case but relevant for Nigerian applications where real-time features are bottlenecked by the round-trip time to a distant coordination server.

The Nigerian Infrastructure Advantages Beyond Latency

Edge deployment on Cloudflare provides three advantages beyond raw latency that are particularly relevant to Nigerian operations:

DDoS resilience: Cloudflare's network absorbs and mitigates distributed denial-of-service traffic before it reaches origin infrastructure. Nigerian businesses, particularly in financial services and payments, face elevated DDoS risk. An application behind Cloudflare Workers absorbs attack traffic at the edge without the origin server seeing it.

Submarine cable failure tolerance: Nigeria's internet connectivity depends significantly on the SAT-3, MainOne, Glo-1, ACE, 2Africa, and Equiano submarine cables. Cable faults — which occur regularly — can disrupt connectivity to specific regions. Cloudflare's network routes around cable faults automatically, maintaining availability through alternative routing when specific sea cables experience problems.

Nigerian currency and compliance context: Cloudflare's Nigerian PoP means Nigerian user data processes on Nigerian infrastructure for the initial request handling. This is relevant for NDPR data residency guidance, which recommends that data of Nigerian individuals be processed within Nigeria where practicable.

Where Edge Computing Has Limits

Cold database connections: Workers processes are isolated and do not maintain persistent database connections. Each Workers invocation that requires a database connection must negotiate a new one. For Cloudflare D1 and Hyperdrive (Cloudflare's connection pooler), this is handled by the platform. For external PostgreSQL servers, connection overhead can partially offset edge compute savings.

Binary and file processing: Workers has a 10ms CPU time limit per request for free-tier invocations and supports larger operations on paid plans, but it is not designed for CPU-intensive operations. PDF generation, image transformation, video processing, and scientific computation belong on standard server instances.

Long-running processes: Workers are designed for request-response cycles, not long-running tasks. A data export job that takes thirty seconds, a machine learning batch job, or a report compilation operation requires a background worker or a standard server, not an edge runtime.

Legacy protocol support: Some banking APIs and government service APIs in Nigeria communicate over protocols or connection patterns that edge runtimes do not support well. Where direct communication with legacy systems is required, a traditional server acting as an intermediary is necessary.

The Architecture We Use

Our default architecture for new Nigerian business applications:

Cloudflare Workers + Next.js (via @opennextjs/cloudflare) for the application layer — handles all request routing, authentication, SSR, and static serving at the edge
Cloudflare D1 for application state, user data, and operational records — SQLite at the edge, queries co-located with the compute
Cloudflare R2 for file storage — static assets, user-uploaded documents, generated reports — served from the edge without egress fees
Cloudflare Queues for background job dispatch — decouples heavy processing from request handling
Origin server (where needed) for compute-intensive operations, external database queries, and legacy system integration

This architecture serves Nigerian users from Nigerian infrastructure for every user-facing interaction, routes only genuinely origin-appropriate work to remote servers, and produces Core Web Vitals scores significantly better than equivalent applications on US-East-only deployments.

For existing applications migrating to this architecture: the largest gains come from moving authentication and frequently-accessed API routes to edge first. A full application migration is not required to capture the primary latency improvements.

The conversation about infrastructure is often treated as a developer preference discussion. For Nigerian businesses with web applications, it is a user experience and revenue conversation that deserves attention from everyone who cares about whether the product works well for its users.

Performance Optimisation as Revenue Strategy — How web performance affects your bottom line
Uptime SLAs: What Hosting Providers Promise vs Deliver — Understanding infrastructure reliability
Offline-First Applications for Nigerian Users — Building for unreliable connectivity