The performance of everything is limited in one way or another by ‘c’.
Not just WAN links, but the data centre Ethernet as well. The distance to the disks matters. The physical size of the motherboard. The placement of caches, etc…
When people say things like “putting the compute near the data” they’re implicitly talking about overcoming the limits imposed by the speed of light.
When you hear about an N+1 performance issue in some ORM, that’s bad because of the speed of light.
When you test your LAN with “ping”, you’re lying to yourself because it won’t show measurements below 1 ms, which is an eternity.
I just told you how much compute can occur in just 10 nanoseconds.
Go ping something. Look at the “1 ms” in the output. Go back to my post and work out what can occur in 1,000,000 nanoseconds. Go look at the 1 ms again.
Repeat until you have an epiphany about your zone redundant Kubernetes-hosted cloud native microservices architecture.
Your ping is 156,000 nanoseconds. You just saw that you can in principle do about 6,400 computations per 30ns, so... that's about 33 million arithmetic calculations per round-trip, within the data centre.
I hope this makes you see every unnecessary network hop in a different light.
PS: It typically takes 3 round-trips to establish a TCP connection, and 5-7 for a TLS connection. A database connection over TLS needs a few more. And then you have load balancers, firewalls, proxies, envoy, ingress, dapr, and, and, and...
Datacenter Ethernet has too much overhead to make a difference in almost all cases. Disks have an even higher overhead:distance ratio. The size of a motherboard only matters for signal integrity, not that half a nanosecond extra. Cache location inside a chip can matter, but even then size is a significantly bigger factor than location.
Oh group velocity.
Speed of light is not exactly a relatable point of reference.