KE = ½mv²: the quadratic that quietly governs your rate limiter

4 min read 1 source biomimicry_analogy
├── "The v² comes from a simple geometric fact: faster objects cover more distance while the force is acting"
│  ├── Physics Stack Exchange accepted answer (Physics Stack Exchange (2011)) → read

The accepted answer derives ½mv² from Work = Force × Distance. Because average velocity during acceleration from 0 to v is v/2, the distance covered scales with v, and combined with the impulse-momentum relation F·t = m·v, this geometric fact — not a notational coincidence — produces the quadratic dependence on speed.

│  └── top10.dev editorial (top10.dev) → read below

Frames the quadratic as the geometric consequence of a faster object covering more ground during every instant the force is applied, so even an unchanged force does more work at higher speeds. Argues this clean mental model explains a class of system-performance failures developers routinely misdiagnose as the system simply 'getting slow.'

├── "The deeper justification is symmetry — Galilean relativity and Noether's theorem force the quadratic form"
│  └── @HN commenters invoking relativity and Noether (Hacker News) → view

Top comments argue the v² is not arbitrary but the unique form consistent with Galilean relativity (kinetic energy differences are frame-invariant) and with energy conservation derived from time-translation symmetry via Noether's theorem. Under this view, any other power of v would break the symmetries that make classical mechanics consistent across reference frames.

├── "½mv² is only an approximation — the real expression is the leading term of a relativistic Taylor expansion"
│  └── @HN commenters citing (γ−1)mc² (Hacker News) → view

Several commenters note that ½mv² is just the low-velocity limit of the relativistic kinetic energy (γ−1)mc². The quadratic isn't fundamental — it falls out as the first non-trivial term of a Taylor expansion, which is why the simple Newtonian picture breaks down as v approaches c.

└── "The physics is a useful mental model for software performance failures that scale quadratically"
  └── top10.dev editorial (top10.dev) → read below

Argues the same quadratic shows up across queueing theory, retry storms, and other on-call failure modes, and developers keep being surprised by it. The kinetic-energy derivation provides a clean intuition — small increases in load do disproportionately more 'work' on the system — that helps diagnose problems otherwise written off as the system just being slow.

What happened

A Physics Stack Exchange thread from 2011 — *"Why does kinetic energy increase quadratically, not linearly, with speed?"* — climbed back to the HN front page this week with 154 points. The question is the kind a sharp ten-year-old asks and a tired physics professor waves off: if I double my speed, why does the energy required quadruple instead of double?

The accepted answer is short and unforgiving. Work equals force times distance. To accelerate from 0 to v, the average velocity over that interval is v/2, so the distance traveled while the force is applied scales with v. Multiply the force (which scales with v through the impulse-momentum theorem, F·t = m·v) by that distance, and you get ½mv². The v² is not a coincidence of notation. It is the geometric consequence of the fact that a faster object covers more ground during every instant the force is acting on it, so the force does more work at higher speeds even though the force itself is unchanged.

The HN thread reads like a graduate seminar that occasionally remembers it is on a public forum. Top comments invoke Galilean relativity (energy is frame-dependent, so the v² has to do something elegant under frame shifts — and it does: kinetic energy differences are invariant), Noether's theorem (energy conservation falls out of time-translation symmetry, and the quadratic form is the unique one that makes the math work), and the obligatory reminder that at relativistic speeds the whole thing is the leading term of a Taylor expansion of (γ−1)mc².

Why it matters

The reason a 2011 physics question is interesting to working developers in 2026 is that the same quadratic shows up everywhere in our systems, and we keep being surprised by it. The physics gives us a clean mental model for a class of failures we routinely misdiagnose as "the system got slow."

Consider four examples from a normal week of on-call.

Queueing theory. The M/M/1 formula for average wait time is ρ/(1−ρ) · (1/μ), where ρ is utilization. As ρ approaches 1, wait time doesn't grow linearly — it grows hyperbolically, and the dominant term near saturation is quadratic in 1/(1−ρ). A queue at 80% utilization has 4× the wait of a queue at 50%, not 1.6×. Every engineer who has watched a service degrade gracefully until it didn't has met this curve. The physics-class intuition — *the faster you go, the more ground each unit of force has to cover* — is the same intuition. At high utilization, each additional request finds more work already in flight.

Retry storms. A client that retries on failure with no backoff doubles its request rate when the server is at 50% failure. The server, now at higher load, fails more requests, which triggers more retries. The feedback is multiplicative, not additive, and the load curve against time looks like… a parabola, until it looks like a wall. AWS's published guidance on exponential backoff is, in physics terms, a damping coefficient on a system that would otherwise resonate.

Hash collisions and birthday-paradox bounds. The probability of a collision in a hash table of size n after k insertions scales as k²/2n. Doubling your insertion rate quadruples your collision rate. If you have ever watched a Redis cluster's p99 latency double after a 10% traffic increase, you have watched v² in action.

GC pressure under allocation rate. Young-generation collection time in most generational GCs scales roughly with live-object count, but allocation rate combined with promotion rate creates a quadratic in old-gen pressure. A 2× write rate is not 2× GC overhead — it's closer to 4× once you cross the promotion threshold.

None of these are surprises if you internalize that physical systems with conserved quantities tend toward quadratic cost functions, because the cost is the integral of a linear thing over the linear thing itself. Force over distance. Requests over time-in-queue. Insertions over already-inserted. The shape repeats because the math underneath repeats.

What this means for your stack

First, stop sizing capacity off of mean load. If your traffic is 1000 RPS average and 3000 RPS peak, your worst-case cost is not 3× — it's closer to 9× once queueing dominates. The right anchor for capacity is the peak squared divided by the mean, not the peak itself. This is why Google's SRE book is so insistent on tail latency: the tail is where the v² lives.

Second, the cheapest mitigation for a quadratic problem is to reduce v, not to add capacity. Doubling your fleet to handle a 2× traffic spike works if cost is linear. It doesn't if cost is quadratic — you need 4× the fleet, and you'll discover this at 3 AM. Rate limiting, request shedding, and admission control are not nice-to-haves; they are the engineering equivalent of slowing down. The car analogy in the Physics SE thread is exact: it takes 4× the braking distance to stop from 60 mph as from 30 mph, because the energy to dissipate scales as v². You cannot brake your way out of a quadratic; you have to not be going that fast.

Third, budget for v² in your SLOs. If your latency SLO is "p99 < 500ms at 1000 RPS," you have not specified what happens at 1500 RPS, and the honest answer is "the wheels come off non-linearly." Modern SLO frameworks (Google's, Honeycomb's, the SRE Workbook's) increasingly express targets as functions of load, not constants. That's the v² showing up in the contract.

Looking ahead

The reason a 14-year-old physics question keeps resurfacing on HN is that the people building software keep rediscovering the same lesson the people building bridges learned a century ago: linear models lie about the world, and the lie gets worse the faster you go. The next time a system degrades faster than you expected, the answer is probably not "add more boxes." The answer is probably ½mv², in a costume.

Hacker News 365 pts 199 comments

Why does kinetic energy increase quadratically, not linearly, with speed? (2011)

→ read on Hacker News
cubic_earth · Hacker News

It&#x27;s easiest to visualize in terms of conversion from potential energy.We know intuitively that a ball atop a 20ft ladder has twice the potential energy of a ball atop a 10ft ladder. And we also know when they fall, by the time they reach the ground and all the potential energy has been convert

throw0101a · Hacker News

Fun little anecdote:A blue care is travelling along at 70 units, and a red car (exact same make and model) is catching up to it going 100. When they&#x27;re both right beside each other a bend in the road reveals an obstacle blocking both lanes, so both cars brake at the same intensity and decelerat

abetusk · Hacker News

Ron Maimon uses an argument that relies purely on symmetry, which circumvents the standard explanations, including many in this thread. In some sense, this is the simplified version of Noether&#x27;s theorem (as far as I understand it).As an aside, I believe Ron Maimon&#x27;s account was suspended a

GlibMonkeyDeath · Hacker News

For me, the most intuitive explanation is that:Force = change in momentum with timeEnergy = Force x distanceNow consider how much energy can be dissipated by a tiny change in momentum over a small distance dx, when we are at a given velocity v:dE = Fdx = (dp&#x2F;dt)dx = m(dv&#x2F;dt)dx = mdv(dx&#x2

Tazerenix · Hacker News

Here&#x27;s how to appreciate it in terms of the counterfactual:Suppose kinetic energy was E = m|v| instead, linearly dependent on speed |v|. What does that mean for the universe?The traditional Lagrangian is L = 1&#x2F;2 mv^2 - V(x). This kinetic energy gives a different formula:L = m|v|ln|v|-V(x).

// share this

// get daily digest

Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.