How many microseconds of latency does each kilometer of fiber add?

Light travels at ~200,000 km/s in optical fiber (~2/3 of vacuum speed). That's 5 microseconds per kilometer of fiber, one-way. New York to London (~5,600 km) adds 28 ms one-way from propagation alone. New York to San Francisco (~4,100 km) adds 20.5 ms. These are fundamental physics limits — no amount of engineering reduces propagation delay except moving the endpoints closer together.

How many microservices can I chain before hitting a 200ms p99 SLA?

At 5ms average p99 per service and serial fan-out (service A calls B which calls C), 12 services consume 60ms of processing alone. Add 2ms per hop for serialization and network variance, and you're at ~84ms before propagation, database queries, or external API calls. With parallel fan-out (service A calls B, C, D concurrently and waits for the slowest), the budget scales with the critical path depth, not total service count. The latency budget calculator models both patterns.

Why does p99 latency matter more than average?

At 1,000 requests/second, p99 = 200ms means 10 requests every second take 200ms or more. Those 10 requests are disproportionately the ones users notice — the slowest 1% of page loads often contain the checkout flow, the login page, or the API call that blocks the entire UI. If your frontend fires 5 API calls per page and you target p99 = 200ms per service, the page-level p99 with serial dependencies is closer to p99 × depth, not p99.

Latency Budget Calculator — End-to-End Delay Decomposition

📐 Network Path & Workload Profile

Configure distance, bandwidth, payload size, and compute time. The engine computes propagation (speed-of-light), transmission (packet serialization), queueing, and processing delay. Remaining budget = your application's ceiling.

Target End-to-End Latency SLA (ms)

Scenario Preset

One-Way Fiber Distance (km)

Network Bandwidth (Mbps)

Payload Size per Request (KB)

Response Size (KB)

Network Hops (routers/switches)

Avg Queue Depth per Hop (μs)

Protocol / Transport

Estimated Server Processing (ms)

Serialization Format

📊 Latency Budget Allocation

Propagation

Serial

Queue

Protocol

App

Slack

Propagation

Transmission

Serialization

Queueing

Protocol Handshake

App Processing

Remaining Slack

Component	Latency (ms)	% of Budget	Notes

⏱️ Latency Reference: Typical Component Costs

Common latency values observed in production distributed systems. Use these as calibration points when building your budget.

Operation	Typical Latency	Context
L1 Cache Reference	~1 ns	CPU core-local
L3 Cache Reference	~12 ns	CPU die-shared
Main Memory (DRAM) Access	~100 ns	NUMA local node
NVMe SSD 4KB Random Read	~100 μs	PCIe Gen4 x4
Network: Same-AZ (AWS/GCP)	~0.5–1 ms	RTT, within datacenter
Network: Cross-AZ (same region)	~2–3 ms	RTT, metro fiber ring
Network: Cross-Region (US East→West)	~60–70 ms	RTT, ~4,500 km fiber
Network: US→Europe (NY→London)	~70–80 ms	RTT, transatlantic fiber
Network: US→Asia (SF→Tokyo)	~110–130 ms	RTT, transpacific fiber
Fiber Propagation (speed of light)	~5 μs/km	One-way, ~0.67c in glass
TCP 3-Way Handshake	1 × RTT	SYN → SYN-ACK → ACK
TLS 1.3 Handshake	1 × RTT	After TCP established
TLS 1.2 Handshake	2 × RTT	After TCP established
DNS Resolution (cached)	~0.1–1 ms	Local resolver cache hit
DNS Resolution (uncached)	~10–100 ms	Recursive lookup chain
Kernel TCP Buffer Copy	~5–10 μs	Per 64KB segment
Context Switch (thread)	~1–10 μs	OS scheduler overhead

Latency Budgeting: Why "Average" Is Dangerous

End-to-end latency is the sum of many independent contributors — and each one has a distribution. Designing systems for average latency is a trap: a service that averages 50 ms can easily have a p99 of 500 ms once you account for queueing, TCP retransmissions, GC pauses, and tail-latency amplification in fan-out architectures.

The discipline of latency budget decomposition forces architects to allocate concrete millisecond budgets to each layer of the stack. If you're building a web service with a 200 ms p99 SLA and the network RTT already eats 70 ms (cross-region fiber) plus 30 ms for TLS handshake, you have only 100 ms left for DNS, load balancer, application logic, database queries, and serialization. That's the budget — and exceeding it means violating your SLA.

The Physics of Fiber: Propagation Delay Is Non-Negotiable

Light travels through optical fiber at approximately 200,000 km/s (about 67% of its speed in vacuum). This gives a one-way propagation delay of ≈5 microseconds per kilometer. For a 4,500 km cross-continental fiber path (US East to West Coast), the one-way propagation is ~22.5 ms — and a round trip adds up to 45 ms before a single byte of application data moves. This is a hard floor set by physics; no amount of bandwidth or optimization can reduce it.

For reference: New York ↔ London (~5,600 km) ≈ 28 ms one-way; San Francisco ↔ Tokyo (~8,200 km) ≈ 41 ms one-way; Sydney ↔ Singapore (~6,300 km) ≈ 31.5 ms one-way. These numbers should be the first entry in any latency budget.

Transmission Delay: Packets Take Time to Serialize

Transmission delay is the time required to push all bits of a packet onto the wire: packet_size / bandwidth. A 1,500-byte packet on a 1 Gbps link takes ~12 μs to transmit. On a 100 Mbps link, the same packet takes ~120 μs. While small, this delay compounds with payload size and the number of packets per request (request + response headers, body fragmentation, ACKs).

The key insight: bandwidth reduces transmission delay, but it cannot reduce propagation delay. Adding more bandwidth to a cross-country link won't make the light travel faster — it only reduces the time to serialize the bits. For latency-sensitive workloads with small payloads, propagation dominates; for bulk data transfers with large payloads, transmission dominates.

Queueing Delay: The Hidden Budget Killer

Queueing delay at each router hop is the most variable component and the primary driver of tail latency. At 50% link utilization, queueing delay is typically near zero. At 90% utilization, queueing delay can spike to 10–100× the baseline — this is why operating networks above 60–70% utilization is dangerous for latency-sensitive traffic. Bufferbloat (excessive buffering in routers) can add hundreds of milliseconds to p99 latency even on otherwise fast paths.

For latency budget planning, assume 50–100 μs of queueing per hop at moderate utilization, and budget an additional 2–5× multiplier for tail events. If you have 10 hops between client and server, queueing alone could consume 1–5 ms at p50 and 5–25 ms at p99.

Protocol Overhead: Handshakes Are Expensive

Establishing a new connection requires protocol handshakes that consume round trips before any application data flows:

Protocol Stack	Round Trips Before Data	Example (60 ms RTT)
TCP (SYN/SYN-ACK/ACK)	1 RTT	60 ms
TLS 1.3 over TCP	2 RTT total (1 TCP + 1 TLS)	120 ms
TLS 1.2 over TCP	3 RTT total (1 TCP + 2 TLS)	180 ms
QUIC (UDP + TLS 1.3 built-in)	0–1 RTT (0-RTT resumption)	0–60 ms
HTTP/1.1 (new connection per request)	TCP + TLS per request	120–180 ms per request
HTTP/2 (multiplexed, keep-alive)	Amortized over many requests	~0 ms incremental

This is why connection pooling, keep-alive, and QUIC/HTTP3 adoption are critical latency optimizations — they amortize the handshake cost across many requests. A cold connection to a server 60 ms away can consume your entire 200 ms budget before application processing even begins.

Tail Latency Amplification in Fan-Out Architectures

Modern microservice architectures often fan out a single user request to dozens of backend services. If each service has a p99 latency of 10 ms and the request touches 20 services, at least one of those 20 will hit its p99 tail with probability 1 − (0.99²⁰) ≈ 18%. In other words, nearly 1 in 5 user requests will experience a tail-latency event. The solution: set per-service latency budgets much tighter than the end-to-end SLA, use hedged requests (send to multiple replicas, take the first response), and implement circuit breakers that shed load when budgets are exceeded.