CONCEPT Cited by 1 source

Constant work pattern¶

Constant work is Colm MacCárthaigh's named AWS reliability pattern: build systems that do the same amount of work regardless of load. Popular metaphor: a coffee urn that keeps hundreds of cups warm whether three people show up or three hundred.

(Reference: AWS Builders' Library — Reliability and constant work.)

The core property¶

Instead of a workload whose cost scales with N (number of requests, number of tenants, number of active flows), constant-work systems scale with something you control at boot time — fleet size, configured capacity, static footprint — and do that same amount of work every interval, regardless of whether they're serving 1 or N requests.

Corollary properties:

Predictable: p50 ≈ p99 because the work is the same every interval.
Overload-resistant: the system doesn't have a mode where "under load I try harder and tip over." There is no try-harder mode.
Boot-time amortizable: expensive setup runs once at boot, not continuously during operation.

AWS Lambda's canonical instance¶

The 2026-04-22 Lambda networking post is the wiki's canonical disclosure of a constant-work decision in production: instead of creating network namespaces + devices on demand during function invocation (paying kernel-device-creation cost whose per-operation latency grows with N), Lambda pre-creates all 4,000 networks at worker boot (~3 minutes of boot cost). (Source: sources/2026-04-22-allthingsdistributed-invisible-engineering-behind-lambdas-network.)

Ravi Nagayach's quote: "absorbing the cost once at boot rather than paying it continuously during operation."

Key decision rationale: "Lambda workers cycle infrequently compared to microVMs, which changes the math entirely" — the base rate of create-vs-use decides whether the amortization works. Because workers live much longer than individual micro-VMs, paying 3 minutes once at boot beats paying seconds distributed across thousands of invocations over the worker's lifetime.

See patterns/pre-create-all-network-slots-at-boot.

When constant-work applies¶

Creation cost is non-trivial (kernel device creation, JVM warmup, TLS handshake, ML-model load).
The base-rate of creation >> base-rate of the containing substrate's churn (the network-slot case: 4,000 slots × frequent VM turnover >> worker reboots).
You can plausibly bound the maximum N at boot (Lambda knows ahead of time that each worker needs ≤ 4,000 slots; a system where N is unbounded can't pre-allocate).

When it doesn't¶

N is truly unbounded — you can't pre-allocate ∞.
The substrate's reboot rate approaches the use rate — the amortization collapses if the worker reboots before the pool is consumed.
The create cost is already trivial — premature optimization.

concepts/aggregate-demand-smoothing — works well alongside constant work: many tenants bursting into a constant-work substrate produce a smooth aggregate load, further improving the economics.
concepts/tail-latency-at-scale — constant work is one of the few disciplines that actually flattens the tail (p99 ≈ p50), vs. hedged requests or backup requests which mask it.
patterns/warm-pool-zero-create-path — the specific pattern family; constant-work is the first-principles articulation.

Seen in¶

sources/2026-04-22-allthingsdistributed-invisible-engineering-behind-lambdas-network — canonical first-person invocation of Colm MacCárthaigh's constant-work principle by the Lambda networking team, applied to per-worker network-slot pre-creation. The post explicitly names the Builders' Library article as the source framing.