A lot of it depends on whether or not the content you're delivering is a static file, or if you're transcoding something. When its a static file, your job is "easier" in that you can use sendfile, and (with hardware kTLS offload) avoid having the CPU touch any data being sent (the Netflix case). When you have a gigantic long tail, and are transcoding a lot of traffic, then optimizations like sendfile and kTLS hardware offload matter a lot less. I imagine Google falls more on one side of the spectrum, and we fall on the other.

> When you have a gigantic long tail, and are transcoding a lot of traffic [...]

Do you mean to say “YT does JIT transcode” or simply that the huge long-tail corpus means that transcode optimization >>> delivery benefits? :)

Other things to factor in: different mix of mobile users & geographies (incl. access networks), software stacks, hardware costs/goals/footprint, etc.

What hardware are you using with hardware kTLS offload?

We've tried both Chelsio T6 and Mellanox ConnectX-6 Dx in prototypes like this.

YouTube is markedly similar to Netflix architecturally I’m sure (precompute ahead of time) and uses quic.