Most edge computing writing assumes a world where the nearest data centre is twenty milliseconds away. In that world, edge is a refinement. In Lagos, where a round trip to the closest major region can run past 150 milliseconds, it is often the difference between a system people use and one they work around.
Where the latency actually goes
Latency is rarely one number. A single user action might involve an authentication check, three API calls and a database write. If each of those crosses the same long link, the delays compound. Users do not experience 150 milliseconds; they experience six of them stacked together, and they call the application slow.
What belongs at the edge
- Anything in a tight interaction loop: form validation, search-as-you-type, live dashboards.
- Anything that must keep working when the link drops, which in practice means anything a field team depends on.
- Aggregation. Sending a thousand sensor readings to a distant region to compute one average is a waste of a link you cannot widen.
What does not
Batch reporting, model training, long-term storage and anything with strong consistency requirements are usually better left central. Distributing them buys milliseconds and costs you correctness, which is a poor trade.
The honest constraint
Edge deployments multiply the number of places where something can break. Every edge node is a machine that needs patching, monitoring and eventually replacing. Teams that add edge without adding operational capacity end up with a faster system that is down more often. Decide the operational model before the architecture.