Shards and placement

Time picks the epoch, hash picks the shard#

The default epoch has 128 store shards, 256 queue shards and 16 index shards. The larger staging epoch used for recent tests has 256 stores and 512 queues. These are configured counts, not platform limits.

The routing function takes the run’s ULID time, finds the applicable epoch, then hashes the run ID with FNV-1a to select a store. Newer epochs have distinct object-name prefixes. Dispatched steps use their keys to spread delivery work.

[
  { "from": 0, "store": 128, "queue": 256, "index": 16 },
  { "from": 1800000000000, "store": 256, "queue": 512, "index": 16 }
]

Append only. Deploy consistent routing to every relevant Worker before the new epoch’s activation time. Editing an old epoch does not migrate data; it changes where callers look for it.

A location hint is a hint#

LOCATION_HINT requests a placement region for newly created objects. It does not guarantee residency, the same data center, or that an existing object moves when the setting changes.

The store first touches the workflow runner without a hint, favoring placement near the store. This improves the chance that repeated state/execution calls are short. It does not prove physical colocation.

Sequential probes vary substantially across run placements. Recent 2k-step samples ranged from about 130 to 395 seconds. A run can have little VM work yet spend most of its time between sequential state calls.

Why creation throughput is high#

Independent starts distribute across store and queue shards. There is no global directory lookup, and new-run listing updates are not on the critical acknowledgment path. Bindings avoid an application-managed HTTP authentication layer between our components.

The load generator ran on Workers with the same region hint as the state, avoiding a laptop-to-region round trip per request. That exposes backend admission capacity better than a distant single client.

Many runs scale better than one enormous run#

A single run still has one ordered store, replay state and a per-isolate memory budget. More queue shards can fan its steps out, but every completion eventually returns to that ordered state.

Request-scoped batching removed quadratic response amplification during first fan-out. A turn gathers up to 500 items per call, with two calls in flight, and stale reports are bounded. A current QuickJS sample passed 30k parallel steps; 35k hit executor memory limits. Batching does not remove the isolate budget.

Use independent runs for independent work. Do not treat “no configured event cap” as unlimited throughput or unlimited memory in one run.