Global Video Delivery: Regions, Edge & Data Residency

Why this matters

A platform that tests beautifully in San Francisco can be unwatchable in Lagos or Lima, and the team often does not find out until the support tickets arrive, because the cause is invisible from a head-office network: the viewer is simply too far from the nearest copy of the video. Geography decides startup time, startup time decides abandonment, and abandonment decides whether a launch in a new market succeeds — so "which regions do we actually serve well, and how" is a product question, not a back-office networking detail. This article is for the founder, product manager, or streaming engineer who is taking a service into more than one country and needs to understand the moving parts well enough to brief a CDN vendor, budget for the regions that are genuinely hard, and avoid the legal trap of moving viewer data somewhere it is not allowed to go. By the end you will be able to explain why a viewer in one country gets a fast start and another gets a spinner, what to do about the regions every global CDN is thin in, and why "where the bytes are served" is a different question from "where the data is stored" and "where the show is allowed to play."

A one-minute refresher: the corner store, now worldwide

This article builds on how a CDN delivers video and the origin mechanics in origin and origin shielding; here is the one idea you need in front of you.

A content delivery network — the worldwide fleet of caching servers, called a CDN, that holds copies of your video near viewers — works like a chain of corner stores stocked from one central warehouse. The origin is the warehouse (the one true copy of every file); the CDN's edge locations, grouped into points of presence (a PoP is a CDN site in a city, with its servers and network links), are the corner stores. When the nearby store has what the viewer asked for, that is a cache hit — fast and cheap. The whole point of the network is to keep viewers shopping at a store near them rather than driving to the warehouse.

Geography is the question this refresher hides: how near is "near," everywhere on Earth? In a city with a PoP a few kilometres away, very near. In a region where the closest PoP is on another continent, not near at all — and that gap, measured in milliseconds of distance, is the subject of this article.

Distance is a tax, and the unit is milliseconds

Start with the physics, because it is the floor under everything else and it never goes away. Light in a vacuum travels about 300,000 kilometres per second, but light in the glass of a fibre-optic cable travels at roughly two-thirds of that — about 200,000 km/s. Engineers turn that into a rule of thumb: one kilometre of fibre adds about 5 microseconds of one-way delay, so a round trip (down and back) costs about 10 microseconds per kilometre, or 10 milliseconds for every 1,000 km. This is the "5-microsecond rule," and no equipment upgrade beats it — it is the speed of light in glass.

Now the catch that makes it worse: fibre does not run in straight lines. Cables follow coastlines, railway corridors, and the seabed routes of submarine cables, so the real path between two cities is commonly 1.5 times the straight-line (great-circle) distance or more. The distance that matters is the length of glass, not the line on the map.

Walk the arithmetic out loud, because the size of the number is the whole argument. Take a viewer in São Paulo and a server in Northern Virginia (US-East), the default "nearby" cloud region for the Americas if you have not built out South America:

Great-circle distance, São Paulo → Northern Virginia ≈ 7,600 km
Real fibre path ≈ 1.5× ≈ 11,000 km of glass
Round-trip propagation = 11,000 km × 10 µs/km = 110 ms
   …that is JUST light making the round trip, before any server works.

Starting a protected adaptive stream is not one round trip. The player must:
   resolve DNS → open the connection → negotiate TLS
   → fetch the manifest → fetch the init segment → fetch the first media segment
   ≈ 4–6 round trips before the first frame appears.

Distance tax ≈ 5 round trips × 110 ms ≈ 550 ms of pure delay
   added on top of every server's own processing time.

Put an edge IN São Paulo (a few km away, < 2 ms round trip):
   the same 5 round trips cost ≈ 5 × 2 ms = 10 ms.
   The distance tax falls from ~550 ms to ~10 ms.

That half-second is not a rounding error. The time from tapping play to the first frame, called startup time (or video start time), is one of the strongest predictors of whether a viewer stays or abandons the stream — we cover the measurement in quality of experience: startup time and rebuffering. Newer transport protocols help at the margins — TLS 1.3 trims a handshake round trip and QUIC can start data in zero round trips — but they shave the number of trips, not the length of each one. The only way to cut the length is to shorten the glass: put a copy of the video in the region. That single fact is why "global delivery" is really "regional delivery, everywhere."

Figure 1. The distance tax. Round-trip time rises about 10 ms per 1,000 km of fibre, and a stream start stacks several round trips — so a cross-continent viewer can lose half a second before the first frame that an in-region edge would save.

How a request finds the nearest edge: GeoDNS and anycast

If the answer is "put an edge in the region," the next question is mechanical: when a viewer presses play, how does their request end up at the right edge instead of some random one? Two techniques do almost all of this work, and most large CDNs use both together.

The first is GeoDNS (geographic DNS). Every device finds a server by first asking the Domain Name System — the internet's address book, defined in IETF RFC 1035, that turns a name like video.example.com into a numeric IP address. With GeoDNS, the CDN runs its own address book and gives a different answer depending on where the question seems to come from: a resolver that looks Brazilian gets the address of a São Paulo PoP; one that looks German gets Frankfurt. Each PoP has its own address, and the name service steers each viewer to a near one. The weakness is in the word "seems": GeoDNS routes by geographic proximity guessed from the resolver's location, and geographically closest is not always network-closest. A peering quirk or a congested link can make a slightly farther PoP genuinely faster, and GeoDNS cannot see that.

The second is anycast, and it is cleverer. Instead of giving every PoP its own address, anycast advertises the same address from many PoPs at once — Tokyo, London, and São Paulo all announce they are the destination for that one IP. The internet's routing system (BGP, the protocol by which networks tell each other "to reach this address, come this way") then delivers each viewer's packets to whichever announcing PoP is topologically nearest — fewest network hops away — automatically. The IETF documents this practice in RFC 4786, "Operation of Anycast Services" (Best Current Practice 126, 2006): a service is made available at one address from multiple locations, and the routing system picks the closest node for each client. The elegance is that routing already knows the shape of the network, so anycast tends to find the network-nearest PoP rather than just the geographically-nearest one, and if a PoP goes offline its address simply stops being announced and traffic shifts to the next-nearest — failover for free.

Think of it as two ways to send someone to the closest branch of a shop. GeoDNS is a directory that prints a different branch address on the flyer it mails to each neighbourhood — useful, but it guesses your neighbourhood from your postcode. Anycast is putting the same phone number on every branch and letting the phone network connect each caller to the nearest one that picks up. In practice CDNs blend them: anycast for the resilient, network-aware routing, GeoDNS and real-user measurements layered on top to correct anycast's occasional bad guess.

Figure 2. Two ways to reach the nearest edge. GeoDNS hands each region a different PoP address based on geographic guesswork; anycast advertises one address from every PoP and lets internet routing deliver each viewer to the network-nearest one.

The map is lumpy: dense regions and the long tail

Here is the fact that vendor maps with their reassuring spray of dots obscure: CDN coverage is wildly uneven, and the unevenness follows population, money, and submarine cables, not need. As of 2026 the large CDNs publish very different footprints — Cloudflare advertises presence in 330+ cities, Akamai claims 4,100+ points of presence and hundreds of thousands of servers embedded in 1,000+ networks across 130+ countries, and AWS CloudFront lists 600+ points of presence across dozens of countries (figures are vendor-reported, 2026, and shift constantly). But those dots cluster. North America, Western Europe, and developed East Asia are thick with PoPs and short fibre runs; large parts of Africa, the interior of South America, Central Asia, and the Pacific islands are thin, and a viewer there is often served from another continent over a long submarine-cable path.

The infrastructure data shows the same shape. Submarine cables carry the overwhelming majority of intercontinental traffic, and peering — the volume of traffic networks exchange directly with each other — is dramatically lower in the underserved regions: industry measurements put South America and Africa at the bottom of the table, a fraction of European or North American peering volume, because there are fewer internet exchange points (IXPs) — the shared facilities where local networks interconnect — and fewer backbone investments. Less local interconnection means more traffic has to leave the region to find content, which means longer paths and higher latency. It also means more fragility: when submarine cables off East Africa were cut in 2024, whole countries saw connectivity collapse, because there was no dense local mesh to fall back on. A "global CDN" badge does not make these regions fast; it just means the provider has some presence somewhere.

This is the long-tail-region problem, and it is where global delivery is actually hard. Three tactics address it, and serious platforms use them in combination.

The first is local interconnection — getting your traffic onto the regional IXP so it reaches local ISPs directly instead of detouring through Europe or the US. Local peering through an IXP can cut latency dramatically because the bytes never leave the region; the African Union and IXP operators have long pushed local exchanges precisely because local routing is often many times faster than the international detour it replaces.

The second, and the most powerful for popular catalogs, is the embedded cache: a caching server placed inside the ISP's own network, as close to the viewer as it is possible to get. This is how the largest streamers conquer the long tail. Netflix Open Connect gives qualifying ISPs an Open Connect Appliance (OCA) — Netflix-supplied hardware that sits in the ISP's facility and serves Netflix content locally; it is a "directed cache" that only serves the IP ranges the ISP advertises to it over BGP, and Netflix provides it at no charge while the ISP provides power, space, and connectivity. Google Global Cache (GGC) does the same for YouTube and Google Play — Google-supplied servers inside the ISP that cache the content popular with that ISP's users and keep the traffic local. The CDNs now offer the pattern as a product too: CloudFront Embedded Points of Presence place AWS edge hardware inside ISP networks to shrink last-mile latency. The principle is identical to an origin shield's logic turned outward: instead of one shield near the origin, you put a cache in the viewer's own ISP, so the popular bytes are already in the building.

The third is the regional or multi-CDN blend: where your global CDN is thin, add a CDN that is strong in that specific region (a local specialist often out-performs a global brand on its home turf), and steer regional traffic to it. This is the regional face of the architecture covered in multi-CDN architecture and orchestration; for the protocol-level internals of how multi-CDN selection works, the Video Streaming section's multi-CDN deep dive goes deeper than we will here.

Table 1. Five ways to reach viewers, and the column that matters for the long tail: does the tactic keep the bytes inside the region, or does it still backhaul across an ocean? Dense-region tactics (anycast, GeoDNS) only keep traffic local where the CDN already has a PoP; the long tail needs embedded caches, local peering, or a regional CDN.

The three geographies founders conflate

Now the conceptual trap that causes the most expensive mistakes, because it is invisible until a regulator or a studio's lawyer points it out. "Geography" in streaming is not one map. It is three, governed by three completely different forces, and they must be designed separately.

The first is delivery geography — where you serve the bytes from. This is everything above: PoPs, regions, routing, embedded caches. It is governed by physics and cost, and the goal is "close to the viewer." A video segment is just bytes; serving it from a nearby edge is a performance decision.

The second is data residency — where the personal data about your viewers is legally allowed to live. This is governed by law, not physics, and the goal is "wherever the rules require." The European Union's General Data Protection Regulation (GDPR, Regulation (EU) 2016/679) does not ban data from leaving the EU, but its Chapter V (Articles 44–50) allows a transfer of personal data out of the European Economic Area only under specific conditions — most cleanly to a country the EU has judged to provide an "adequate level of protection" (Article 45), or otherwise under approved safeguards. Other countries go further into hard localization: Russia's Federal Law 242-FZ requires that personal data of Russian citizens be stored on servers physically inside Russia; China's Personal Information Protection Law (PIPL) and Cybersecurity Law require domestic storage for certain operators and a formal assessment before personal data leaves the country. Over sixty countries now impose some residency or localization requirement, and the count has more than doubled since 2020. Crucially, the video itself is usually not "personal data" — but the viewing records, account details, watch history, and ad-targeting profiles absolutely are, and those are exactly what a careless global architecture replicates into the wrong country. The privacy-law side of this lives in privacy and viewing data: VPPA, GDPR, CCPA.

The third is rights geography — where you are licensed to show a given title. This is governed by content contracts, and the goal is "only where we bought the rights." A film licensed for Germany must not play in France, and the platform enforces that with geo-blocking. This is a different map again from the other two, and it is owned by the licensing layer; we cover it in multi-territory licensing and geo-blocking, not here.

The reason this matters so much is that the three maps rarely line up. You might serve a Russian viewer's bytes from a fast in-country edge (delivery), while their account data must also stay in-country (residency, 242-FZ), while a given Hollywood title is geo-blocked from Russia entirely (rights). Three independent constraints, three independent designs. A team that treats "we're global" as one switch will, sooner or later, serve fast video while quietly breaking a data law or a studio contract.

Figure 3. Three maps, three forces. Delivery geography is governed by physics and cost; data residency by law (GDPR Chapter V, Russia 242-FZ, China PIPL); rights geography by content contracts. They rarely coincide, and each needs its own design.

A worked plan: taking a service into a new region

Put it together as the decision a real team faces when it expands. Say a European SVOD service is launching in Brazil and Nigeria. The reasoning runs in the same order for both, and the answers differ.

For Brazil, the audience is concentrated in a few large coastal metros, the major CDNs all have São Paulo PoPs, and submarine-cable links to North America and Europe are reasonably good. Delivery: enable the in-region PoPs, confirm anycast actually lands Brazilian viewers on São Paulo (measure it — do not assume), and for a popular catalog explore embedded caches in the largest Brazilian ISPs. Residency: Brazil's data-protection law (LGPD) shapes how viewing data is handled, so the analytics and account stores need a compliant design even though delivery is straightforward. Rights: confirm every title's Brazil licence before it appears in the catalog. Brazil is a "dense enough" region — most of the work is configuration and measurement.

For Nigeria, the picture is harder and the budget has to reflect it. PoPs are sparser, more traffic depends on a smaller set of submarine cables, and a cable cut can degrade a whole region at once (as the 2024 West and East African outages showed). Delivery: a global-CDN PoP may be in a neighbouring country rather than in-country, so the realistic options are local IXP peering to reach Nigerian ISPs directly, an embedded cache inside the largest local ISPs, and quite possibly a regional CDN that specializes in African delivery, blended in via multi-CDN. Resilience matters more: with fewer cable paths, a single failure is more likely to be felt, so the delivery plan needs a regional fallback. The latency floor is higher than Brazil's no matter what, so the encoding ladder and the player's startup behaviour (covered in low-latency delivery and live event delivery) should be tuned for a tougher network, not the head-office one.

Two regions, one method: map the audience, choose the delivery tactic that keeps bytes closest, check residency law for the data, check rights for the catalog, and plan resilience for the cable reality. The cost of the two launches is not the same, and pretending it is — budgeting Nigeria like Brazil — is how a new market underdelivers.

Figure 4. Coverage is lumpy. Dense regions get direct in-region edges; long-tail regions backhaul across submarine cables unless you add local peering, an embedded ISP cache, or a regional CDN. The badge "global" hides this difference.

Common mistakes that make a region slow or non-compliant

Most global-delivery failures are not exotic; they are a head-office assumption meeting a region it does not fit.

The headline error is treating "global CDN" as uniform — assuming the latency you measure at the office is the latency everywhere, when the long-tail regions are served from another continent and feel a half-second of distance tax the office never sees. Its cousin is trusting the geographically-nearest PoP over the network-nearest — relying on raw GeoDNS proximity when a peering quirk makes a "closer" PoP slower, instead of measuring real-user latency and letting anycast and real measurements correct the guess. A third is running a single global CDN with a thin region and no local presence, so in-region viewers backhaul across an ocean with no embedded cache and no IXP peering to keep traffic local. A fourth, and the most dangerous, is conflating the three geographies — building one "international" switch that serves bytes, stores personal data, and exposes the catalog identically everywhere, and so quietly violating a residency law (242-FZ, PIPL, GDPR Chapter V) or a licence the moment it crosses a border. A fifth is ignoring submarine-cable single points of failure for a coastal or island region, so one cable cut takes the whole audience down because there was no regional fallback. And the quiet sixth is placing the origin far from the new region without a shield or in-region tier, so even viewers near an edge pay the cross-ocean tax on every cache miss — the failure that ties straight back to origin and origin shielding and shows up on the delivery-observability dashboard as a region with a high startup time and a low cache-hit ratio.

Where Fora Soft fits in

Going global is a scale-and-reach problem before it is a technical one: the question is not "do we have a CDN" but "which regions do we actually serve well, what does each hard region cost, and where is the data allowed to live" — and the regions that look like an afterthought on a coverage map are exactly the ones that decide whether a new market launch works. Fora Soft has built video streaming, OTT/Internet TV, live event, e-learning, and telemedicine software since 2005, across 625+ shipped projects for 400+ clients, much of it for audiences spread across continents, and that work runs straight through this layer: mapping where viewers really are, choosing per-region delivery tactics (anycast and GeoDNS routing, embedded ISP caches, IXP peering, and multi-CDN regional blends), and — just as important — keeping delivery geography, data residency, and content rights as three separate, deliberately designed maps rather than one hopeful switch. When a media company needs a platform that is fast in the regions that are genuinely hard and compliant in the ones with strict data laws, that regional-delivery engineering is the capability we bring.

What to read next

• Multi-CDN architecture and orchestration
• CDN cost engineering: egress, commits, and the 95th percentile
• Quality of experience: startup time and rebuffering

Call to action

• Talk to a streaming engineer — book a 30-minute scoping call to talk through your global content delivery plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Global Delivery & Regional Readiness Checklist — A one-page checklist to work through before taking a streaming service into a new region: map where viewers really are and which regions are long-tail for you, choose the per-region delivery tactic that keeps bytes closest….

References

1. RFC 4786 — Operation of Anycast Services — IETF (J. Abley, K. Lindqvist), BCP 126, December 2006. Defines anycast as making a service available at one address from multiple locations, with the routing system delivering each client to the topologically nearest node — the basis for how a single CDN IP reaches the network-nearest PoP, and how a failed PoP drops out of routing. Tier 1 (official Best Current Practice). https://www.rfc-editor.org/rfc/rfc4786.html (accessed 2026-06-16)
2. RFC 1035 — Domain Names: Implementation and Specification — IETF (P. Mockapetris), November 1987. The Domain Name System that resolves a name to an IP address — the resolution step GeoDNS intercepts to return a region-specific PoP address. Tier 1 (Internet Standard). https://www.rfc-editor.org/rfc/rfc1035 (accessed 2026-06-16)
3. Regulation (EU) 2016/679 (GDPR), Chapter V (Articles 44–50) — Transfers of personal data to third countries — European Parliament and Council, 2016. Article 44 sets the general principle that personal data may leave the EEA only under the Chapter's conditions; Article 45 permits transfer to a country with an "adequate level of protection." The legal frame for where viewing and account data may reside. Tier 1 (statute). https://gdpr-info.eu/art-44-gdpr/ (accessed 2026-06-16)
4. Federal Law No. 242-FZ (Russia) — data localization — Russian Federation, in force 1 September 2015. Requires that personal data of Russian citizens be recorded, stored, and processed using databases located within the Russian Federation. The model "hard localization" requirement. Tier 1 (statute). https://pd.rkn.gov.ru/ (Roskomnadzor, accessed 2026-06-16) — confirm the current official text/translation before publish.
5. RFC 8216 — HTTP Live Streaming (HLS) — IETF (R. Pantos, Ed.), August 2017. The manifest-plus-segments model and live-playlist reload behavior by which every player re-fetches to discover new segments — the per-request pattern that distance multiplies, region by region. Tier 1 (format specification). https://www.rfc-editor.org/rfc/rfc8216 (accessed 2026-06-16)
6. ISO/IEC 23009-1 — Dynamic Adaptive Streaming over HTTP (MPEG-DASH) — ISO/IEC, 2022 edition. Deterministic segment URLs that are identical across viewers, so every region requests the same objects — the property a CDN's regional caches exploit. Tier 1 (format specification). https://www.iso.org/standard/83314.html (accessed 2026-06-16)
7. Open Connect — Appliances and Deployment — Netflix Open Connect, 2026. The embedded Open Connect Appliance (OCA) placed inside an ISP, the "directed cache" model in which an OCA serves only the IP prefixes advertised to it over BGP, and the no-charge-hardware / ISP-provides-power-and-space arrangement — the long-tail-region fix at ISP scale. Tier 4 (first-party engineering). https://openconnect.netflix.com/en/appliances/ (accessed 2026-06-16)
8. Google Global Cache (GGC) — Google (overview), 2026. Google-supplied caching servers deployed inside ISP networks to serve popular YouTube and Google Play content locally and keep traffic within the ISP — the same embedded-cache pattern for the long tail. Tier 5 (institutional overview). https://peering.google.com/ (accessed 2026-06-16)
9. Using Amazon CloudFront with origins and Embedded Points of Presence — Amazon CloudFront Developer Guide, 2026. The 600+ points-of-presence footprint and CloudFront Embedded PoPs placed inside ISP networks to shrink last-mile latency — the CDN-productized version of the embedded cache. Tier 4 (vendor engineering) — PoP counts are vendor-reported and change; re-verify on the 90-day re-baseline. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ (accessed 2026-06-16)
10. It's Time to Learn About Latency — TeleGeography, 2024. The speed of light in fibre (~2/3 of vacuum), the ~5-microsecond-per-kilometre one-way rule, and the point that real cable paths exceed great-circle distance — the basis for the distance-tax arithmetic. Tier 5 (institutional/analyst). https://blog.telegeography.com/its-time-to-learn-about-latency (accessed 2026-06-16)
11. 2024 East Africa Submarine Cable Outage Report — Internet Society Pulse, 2024. Documents how submarine-cable cuts degraded connectivity across multiple East African countries at once — the evidence that long-tail regions with few cable paths carry a single-point-of-failure risk. Tier 5 (institutional). https://www.internetsociety.org/resources/doc/2024/2024-east-africa-submarine-cable-outage-report/ (accessed 2026-06-16)
12. Overview of Internet Exchange Point — African Union, 2026. The case that local IXPs keep regional traffic local and cut latency substantially versus routing through other continents — the interconnection half of the long-tail fix. Tier 5 (institutional). https://au.int/en/overview-internet-exchange-point (accessed 2026-06-16)

Source note (per §4.3.2): the routing and delivery mechanics trace to tier-1 standards — anycast to RFC 4786 (ref 1), DNS to RFC 1035 (ref 2), and the segment/manifest model to RFC 8216 (ref 5) and ISO/IEC 23009-1 (ref 6). The residency constraints are cited to statute — GDPR Chapter V (ref 3) and Russia's 242-FZ (ref 4); the China PIPL reference in the body is statute-level and should be cited directly when the legal article (Block 8.6) is written. Vendor PoP counts (Cloudflare, Akamai, CloudFront; ref 9) are vendor-reported, 2026, and labelled as such because they change constantly. Embedded-cache behavior is first-party from Netflix Open Connect (ref 7) and Google (ref 8). The distance-tax physics (ref 10) is first-principles arithmetic from the speed of light in fibre, not a benchmark. Where general "global CDN" marketing implies uniform latency everywhere, the article follows the infrastructure evidence (refs 10–12) that coverage and peering are deeply uneven.