Creates a new ShardCoordinator instance
Durable Object state provided by Cloudflare runtime
Atomically decrements the key count for a specific shard and updates the last modified timestamp. Used when primary keys are removed or moved from a shard. Prevents negative counts.
The shard binding name to decrement
Promise that resolves when the count is updated
Handles HTTP requests to the Durable Object
Main entry point for all HTTP requests to the ShardCoordinator. Routes requests based on method and path to appropriate handler functions.
Supported endpoints:
?after=<key>&limit=<n>, since 1.4.0)The incoming HTTP request
Promise resolving to HTTP response
Forgets the recorded allocation for a primary key.
Called when a key is reassigned or its mapping deleted, so a later first-touch allocates afresh instead of being handed the stale decision.
The key whose recorded allocation should be dropped
Atomically increments the key count for a specific shard and updates the last modified timestamp. Used when new primary keys are assigned to a shard.
The shard binding name to increment
Promise that resolves when the count is updated
Stops writing the legacy keys and deletes them
Finishes any pending copy first. The phase flips to sql-only before the keys go, so an
interrupted run leaves unused keys behind and calling it again finishes the cleanup.
Afterwards the previous coordinator version cannot read this object; downgrading past
this call is unsupported.
Promise that resolves when the legacy keys are gone
Durable Object for coordinating shard allocation and maintaining statistics
The ShardCoordinator is a Cloudflare Durable Object that provides centralized coordination for shard allocation across multiple database instances. It maintains state about available shards, allocation strategies, and usage statistics.
Key responsibilities:
ctx.storage.sql)State from earlier versions lives under legacy storage keys. The first requests copy it into SQL in pages, and until ShardCoordinator.retireLegacy runs every write also lands on the legacy keys, so the previous version can still read the object. That window is read-only for a downgrade: writes the previous version makes to the legacy keys are not copied back when the object upgrades again, and the new version overwrites them.
Example