Latency doesn’t come from one place. It accumulates across the entire system
Lately I’ve been trying to understand how machines actually communicate and where latency comes from.
A few things that changed how I think:
- A socket is basically a communication endpoint between processes.
- IP addresses identify machines, but ports decide which process receives the data.
- TCP prioritizes reliability and correctness.
- UDP prioritizes speed and low latency.
- In HFT systems, stale market data can be more dangerous than missing data.
The biggest realization was that latency is everywhere.
Not just in slow internet, but in:
- network travel
- kernel processing
- memory access
- scheduling
- queues
- application logic
The deeper I go, the more I realize modern software is mostly systems exchanging messages under constraints.
And most optimization work is really about removing waiting.
Related Reading
The Packet Was Already Late Before My Application Saw It
Today I followed a market data packet from the network card all the way to the application and realized that latency can appear long before our code even starts running.
A System Can Be Technically Working and Still Be Failing Its Users
What happens when a system can process 10,000 requests per second but suddenly receives 15,000? Today's exploration led me through queueing, backpressure, retries, and a different way of thinking about overload.