The Physics of Sub-10ms Serverless Routing: How Edge Networks Beat the Speed of Light

When a developer hears "sub-10ms response time," the first reaction is usually skepticism. Light itself takes about 67ms to travel from New York to Tokyo through fiber optic cable. So how can an API validate a license key faster than a database round-trip?

The answer isn't magic — it's physics, topology, and ruthless elimination of unnecessary hops.

The Speed of Light Problem

Light travels at roughly 200,000 km/s through fiber optic cable (about two-thirds the speed of light in a vacuum). For a request traveling from Singapore to a server in Virginia, that's approximately 15,000 km each way — 30,000 km round trip. At fiber speeds, that's 150ms of pure physics-imposed latency, before your server even begins processing.

Route	Distance (km)	Min RTT (fiber)	Real-world RTT
NYC → London	5,570 × 2	56ms	70-90ms
NYC → Tokyo	10,800 × 2	108ms	150-200ms
NYC → Sydney	16,000 × 2	160ms	250-300ms
Edge PoP → User	50-500 × 2	0.5-5ms	1-8ms

The last row reveals the secret: if your compute runs within 500km of every user, physics is on your side instead of against you.

Anycast Routing: One IP, 300+ Locations

Traditional DNS-based load balancing adds 20-50ms of DNS resolution latency. Anycast eliminates this entirely. With anycast, a single IP address is announced from every edge location simultaneously. BGP (Border Gateway Protocol) automatically routes each request to the nearest point of presence.

// The same IP responds from the nearest edge location
// Client in Tokyo → routes to Tokyo PoP (2ms)
// Client in London → routes to London PoP (3ms)
// Client in São Paulo → routes to São Paulo PoP (4ms)

const response = await fetch('https://api.example.com/validate', {
  method: 'POST',
  body: JSON.stringify({ key: 'LK-xxxx-xxxx', domain: 'myapp.com' })
})
// Response time: 3-8ms regardless of geographic location

BGP Path Selection

BGP selects the optimal path using multiple criteria: AS path length (fewest network hops), local preference (ISP peering agreements), and multi-exit discriminator (MED) values. In practice, this means a request traverses at most 2-3 network hops before reaching an edge function, compared to 8-15 hops for a centralized server.

The Cache-Tier Architecture

Sub-10ms isn't just about proximity — it's about what happens when the request arrives. A three-tier caching architecture eliminates database queries for 95%+ of requests:

1. L1: In-Isolate Memory — V8 isolate-local cache. Sub-microsecond reads. Survives across requests to the same isolate (typically 30-60 seconds). Ideal for hot keys.
2. L2: Edge Key-Value Store — Distributed KV replicated across all edge locations. 1-5ms reads. Eventually consistent with sub-second propagation. Handles 95% of cache misses from L1.
3. L3: Origin Database — Strongly consistent SQL database. 20-100ms reads depending on proximity. Accessed only on KV cache misses (~2-5% of total requests).

// Three-tier cache lookup
const validate = async (key, domain, env) => {
  // L1: Isolate memory (sub-microsecond)
  const l1 = isolateCache.get(key)
  if (l1) return checkDomain(l1, domain)

  // L2: Edge KV (1-5ms)
  const l2 = await env.CACHE.get(`lic:${key}`)
  if (l2) {
    const parsed = JSON.parse(l2)
    isolateCache.set(key, parsed) // Promote to L1
    return checkDomain(parsed, domain)
  }

  // L3: Origin database (20-100ms)
  const license = await db.query('SELECT * FROM licenses WHERE key = ?', [key])
  if (!license) return { valid: false, error: 'invalid_key' }

  // Populate L2 and L1
  await env.CACHE.put(`lic:${key}`, JSON.stringify(license), { expirationTtl: 300 })
  isolateCache.set(key, license)

  return checkDomain(license, domain)
}

Cold Start Elimination

Traditional serverless platforms (Lambda, Cloud Functions) suffer from cold starts of 100-500ms when a new execution environment spins up. Edge compute platforms using V8 isolates instead of containers eliminate this entirely. A V8 isolate starts in under 5ms — often under 1ms — because it doesn't need an OS, a runtime, or a filesystem.

Platform	Cold Start	Warm Start	Isolation Model
AWS Lambda	100-500ms	1-10ms	Container (microVM)
Google Cloud Functions	200-800ms	5-20ms	Container
Edge Functions (V8)	0-5ms	0ms	V8 Isolate

Connection Reuse and TLS Optimization

TLS 1.3 handshakes add 1 RTT (round-trip time) to new connections. At scale, this matters. Edge platforms optimize this through:

• Connection pooling — Keep-alive connections to origin databases, amortizing TLS overhead across thousands of requests
• 0-RTT TLS resumption — Returning clients skip the TLS handshake entirely using session tickets
• HTTP/3 QUIC — Multiplexed connections over UDP eliminate head-of-line blocking
• Early hints (103) — Send response headers before the body is ready

Measuring Real-World Performance

P50 metrics hide tail latency. For latency-sensitive APIs, you need to measure P95 and P99:

// Latency measurement with percentile tracking
const latencies = []

for (let i = 0; i < 1000; i++) {
  const start = performance.now()
  await fetch('https://api.example.com/validate', {
    method: 'POST',
    body: JSON.stringify({ key: testKey, domain: 'test.com' })
  })
  latencies.push(performance.now() - start)
}

latencies.sort((a, b) => a - b)
console.log({
  p50: latencies[499],   // Median: 3ms
  p95: latencies[949],   // 95th percentile: 7ms
  p99: latencies[989],   // 99th percentile: 12ms
  max: latencies[999],   // Max: 45ms (cache miss)
})

When Sub-10ms Matters

Not every API needs single-digit latency. But for license validation, it's critical. Your validation call sits in your customer's application hot path — every millisecond you add is a millisecond their users experience. At 200ms, validation becomes noticeable. At 50ms, it's tolerable. At 5ms, it's invisible.

The physics of networking sets a hard floor on latency. Edge compute doesn't break the laws of physics — it works with them, placing your code within the speed-of-light radius that makes single-digit milliseconds possible.