The Tyranny of the Second: How Our Millisecond Madness Masked Deeper Truths

There is a mantra in our field, repeated so often it has become an unassailable truth: lower latency is always better. We have become obsessed with shaving off milliseconds, celebrating each fractional gain as if it were a moon landing. Our dashboards glow with microsecond precision, our graphs are a forest of peaks and troughs we relentlessly seek to flatten. We chase the phantom of the instantaneous response, convinced it is the ultimate measure of a service's quality. But I want to question this obsession. I want to suggest that in our fervent race to zero, we may have lost sight of what actually matters.

The received wisdom is rooted in a kernel of truth, of course. User experience suffers with noticeable delay. A sluggish webpage, a stuttering video call—these are tangible failures. But somewhere along the way, this practical concern metastasized into an engineering religion. We began to worship at the altar of the p99 latency graph, pouring immense resources into optimizing for the hypothetical user who might, just might, notice a 50ms difference on a Tuesday afternoon. We built complex, fragile systems to eke out these gains, often introducing more potential points of failure than the performance benefit warranted.

The Illusion of the Metric

This is the tyranny of the second, or rather, the millisecond. It’s the illusion that because something is easy to measure, it is the most important thing to measure. Latency is a wonderfully clean, numerical value. It fits neatly into our monitoring systems and makes for compelling, data-heavy presentations. But it is a shallow metric. It tells us how long a request took, but it tells us nothing about the quality of the journey or the outcome. A request can be served in a blazing five milliseconds, yet deliver a corrupted payload, a logical error, or a result utterly irrelevant to the user’s intent. The service is 'fast,' but is it actually working?

In prioritizing speed above all else, we inadvertently demote the richer, more nuanced signals of health. We forget that consistency and predictability are often more valuable than raw speed. A service that reliably responds in 200 milliseconds is far more trustworthy than one that usually responds in 50ms but sporadically spikes to 2000ms, sowing frustration and uncertainty. Our millisecond madness can blind us to these patterns of instability, focusing our attention on the average while the outliers wreak havoc.

True observability asks for more than a timer. It asks about state, about meaning, about outcome. Did the process complete correctly? Was the user’s intent fulfilled? Is the system in a sustainable posture? These are harder questions to answer. They require thoughtful instrumentation, a deeper understanding of the user’s journey, and a willingness to look beyond the seductive simplicity of a latency chart. By breaking free from the tyranny of the second, we can build systems that aren't just fast, but are genuinely reliable, understandable, and truly serving their purpose.

Notes & further reading

A few pages I came back to while writing this: