Waterfall vs parallel
Four independent lookups of about 60ms each — awaited one at a time, then all at once.
Velocity
Removing latency as an architecture, not a list of tricks: optimistic mutation, cache tiers, stampede protection, deferred tails — each measured against the naive version.
Every number on this page was measured on the request that asked for it. Nothing here is a stored figure.
Concurrently — a page about waterfalls should not create one.
Cold, warm, cached
The same value read three times: recomputed every time, then read through the cache. Each read costs about 60ms at the origin.
Stale while revalidate
Two policies, one value, both left to age past a 1s TTL. One declares a stale window and one does not. Takes about 1200ms to run — that wait IS the TTL lapsing.
Cache stampede
100 simultaneous misses for one value. Read the origin count, not the clock — that is what the dependency actually felt.
Deferred tail
A write of about 60ms plus three consequences: awaited before responding, then deferred after it.
What is simulated is the dependency — it sleeps instead of querying Postgres, so a public page cannot put load on the database and a fixed cost keeps the two arms comparable. The mechanisms are the real ones.
Think this pattern could be better? Tell us how.
Leave feedback