The physics case for hosting Canadian traffic in Canada

The claim

Most arguments for keeping Canadian workloads on Canadian infrastructure are legal ones. Those arguments are real but negotiable — contracts, addenda, and standard clauses can move them. The argument that cannot be negotiated is the speed of light in glass, and for a chatty application it is worth more milliseconds than any amount of server tuning you will ever do.

Do the arithmetic yourself

Light in single-mode fibre travels at roughly two-thirds of its vacuum speed, about 200,000 km per second, or 5 microseconds per kilometre. Real fibre paths are not straight lines; a factor of 1.4 to 1.5 over great-circle distance is a reasonable planning assumption.

Toronto to Ashburn, Virginia is about 700 km. Apply the path factor and you get roughly 1,000 km of glass. Round trip:

2 x 1000 km x 5 us/km = 10,000 us = 10 ms floor

Ten milliseconds is the best case, before routers, before the queue at the peering point, before TLS. Toronto to Toronto over a metro path is under 2 ms. You are not going to close a 8 ms gap by buying faster CPUs.

Where 8 ms turns into 800 ms

One page load is not one round trip. Consider a fairly ordinary server-rendered page with a database in the same region as the app server, but the whole stack sitting in Virginia while the customer sits in Mississauga:

• TCP handshake: 1 RTT
• TLS 1.3 handshake: 1 RTT
• HTML request and response: 1 RTT
• Two stylesheet and font fetches on a new connection: 1 RTT (reused connection, parallel)
• One XHR for a personalised header: 1 RTT

That is five round trips. At the Toronto-to-Virginia floor of 10 ms you have added 50 ms; at a realistic measured 22 ms you have added 110 ms. Now add an application that issues a handful of sequential API calls from the browser — a common pattern in checkout flows — and the multiplier grows without anyone changing a line of code.

The version of this that actually hurts is a split stack: application servers in one country, database in another. Every ORM query becomes a cross-border round trip. A page issuing 40 queries — not unusual for an untuned admin screen — pays 40 x 22 ms = 880 ms of pure waiting.

Measure before you argue

Run this from a workstation on the network your customers actually use, not from your office fibre:

curl -o /dev/null -s -w 'dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n' https://example.ca/

The gap between connect and time_namelookup is one round trip. The gap between ttfb and tls is your server's real think time. If connect is 0.024 and ttfb minus tls is 0.011, your server is fast and your geography is slow, and no amount of profiling application code will help.

What a CDN does and does not fix

A CDN with a Toronto point of presence terminates TLS locally, which removes two of those five round trips even when the origin is far away. That is genuinely valuable and it is cheap. What it does not fix is the uncached path: a logged-in dashboard, a cart, a search query, a form POST. Those still travel to the origin. If most of your traffic is authenticated, the CDN is improving the part of your site that was already fast.

The residency question, briefly

PIPEDA does not require that personal information stay in Canada. It requires that you provide a comparable level of protection through contractual or other means when you transfer it for processing, and that you be transparent about it. Several provincial public-sector statutes are stricter, and if you sell to a school board, a health authority or a municipality, expect residency to appear as a hard procurement requirement rather than a preference. Treat legal residency and network latency as two separate decisions that happen to point the same way.

A reasonable default

1. Put the database and the application servers in the same availability zone. Cross-zone is fine; cross-region is a design smell.
2. Put that region in the market where the majority of your requests originate. For most of our clients that is Toronto or Montreal.
3. Put a CDN in front for static assets and cacheable HTML.
4. Keep an off-site backup copy in a second region, ideally a second provider, and check whether your contracts permit that region.

If your users are in Canada and your servers are not, you are paying a latency tax on every interaction, and you are paying it forever.