ReservationStore

Reserved keys: uniqueness across aggregate instances, such as a user name unique within a tenant (documentation/designs/01-programming-model.md §7; 9.x PrepareKey).

A key is unique within its ReservationScope: one aggregate type, one tenant (or ReservationScope.SYSTEM_TENANT for keys unique across the type's tenants) and one namespace. It is held by at most one owner, an aggregate of that type (AggregateRef, compared field by field). The aggregate type is the unit of placement: its reservations live with its log, so two aggregate types that use the same namespace never conflict; a key that must be unique across aggregate types is modelled as an aggregate of its own that holds those keys. A decision reserves it pending with a short time to live, and confirms it once its events are appended: a process that crashes between reserving and appending leaves only a pending reservation that expires, never a key held for good. A confirmed reservation never expires; it ends only when its owner releases it.

Several attempts of one owner may reserve one key at once (a handover, a forward that timed out): a pending reservation records each attempt that reserved it, its holds, and an attempt whose events are surely not appended abandons only its own hold. The key stays reserved while another attempt still holds it, and a confirmed key is never abandoned.

A confirmed reservation records the version of its owner's fact that last confirmed it, and a release names the version of the fact that gave the key up: a release frees only a key no later fact confirmed, so a subscription replaying an old rename (A→B, then B→A) never frees the key a later fact of the owner confirmed again.

Every operation that changes a reservation names its owner and does nothing for anyone else. Expiry is judged by the implementation's clock, so the nodes sharing a store need clocks that agree within a small fraction of the time to live.