Your API response went from 320ms to 95ms after a CDN switch.
Nothing changed on the server. Same origin. Same payload.
The only difference: the CDN started speaking HTTP/3 to your clients.
Here's the setup:
Mobile app → Load Balancer → Origin (NestJS) → DB
Every request goes through the CDN first. Latency is acceptable, until high packet-loss environments (mobile 4G to 5G transitions, flaky WiFi, Asia-Pacific routes). You're seeing 800ms+ tail latency for the p99. The CDN supports HTTP/2 and HTTP/3. What do you enable?
A) HTTP/2 only — multiplexing over a single TCP connection eliminates the old HTTP/1.1 head-of-line problem. Proven, widely supported.
B) HTTP/3 only. Built on QUIC (UDP), eliminates TCP head-of-line blocking entirely, 0-RTT connection resumption. Modern clients handle it fine.
C) HTTP/2 to origin, HTTP/2 to clients. Maximize multiplexing end-to-end, avoid QUIC instability in enterprise firewalls.
D) HTTP/3 to clients, HTTP/2 to origin. QUIC handles the lossy last mile, HTTP/2 handles the stable datacenter leg.
One of these is how Netflix, Cloudflare, and most major CDNs actually handle this in production.
Pick one (A, B, C, or D) and tell me why. Full breakdown in the comments.
If your team is debating CDN config or protocol upgrades, share this. The tradeoff is sharper than most people think.
Drop your answer 👇
30DaysOfSystemDesign #SystemDesign #HTTP3 #WebPerformance
Some comments may only be visible to logged-in visitors. Sign in to view all comments.
For further actions, you may consider blocking this person and/or reporting abuse
