Skip to main content

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.

Fast software does not make everything faster. It removes work from the user's wait.

The ladder

Each rung is cheaper than the one below it. Work down the list before reaching for a faster machine.

  1. 1 Do not compute it critical-path-deferred-tail
  2. 2 Compute it once hierarchical-cache
  3. 3 Compute it before it is requested intent-preloading
  4. 4 Compute it close to the data or the user compute-locality
  5. 5 Compute independent work concurrently no-waterfall-loading
  6. 6 Cache the result stale-while-revalidate
  7. 7 Respond optimistically where safe optimistic-mutation
  8. 8 Defer non-critical work critical-path-deferred-tail

Critical, deferred, background

Getting a piece of work into the right class is usually a bigger win than making it faster.

Critical

Must finish before the result can safely be returned: authentication, authorization, validation, the canonical write, and the data the first render needs.

Deferred

Should happen soon, but nobody waits for it: analytics, search indexing, notifications, derived metadata.

Background

Not attached to this response at all: exports, media processing, AI enrichment, cleanup, expensive projections.

What is measured here

The Data tab executes both arms of each comparison on the request that asks for it — a real 60ms dependency, a real 100-caller stampede, the real cache modules. Measurement surfaces live elsewhere:

When not to

Performance architecture creates complexity, and complexity that buys nothing is a cost. A static site needs asset delivery, preloading and bundle budgets — not Redis, singleflight, read models or distributed tracing.

Instantiate the smallest set your application's actual latency justifies.

Think this pattern could be better? Tell us how.

Leave feedback