MongoReservationStore

The ReservationStore on MongoDB (documentation/designs/01-programming-model.md §7): one collection per aggregate type, wow_reservation__<context>__<aggregate> (the type is the unit of placement, so its reservations follow its log's store), created with its format record on the type's first use. One document per reserved key, {_id: {t: tenant_id, n: namespace, k: key}, tenant_id, key, owner: {tenant_id, id}, expires_at, holds, version}: the key is the _id (the system tenant is the empty string), its tenant and key also plain fields, the shard key's; the owner is of the collection's type. A null expires_at marks a confirmed reservation, version the owner's fact that last confirmed it; a pending one expires at that epoch millisecond and is held by the attempts in holds, without a version. Every operation finds a reservation by its key, so the collection has no index but the _id's (and the shard key's when sharded). The layout is format FORMAT.

Sharded cluster: with MongoSharding.AUTO on a mongos, each collection is sharded by (tenant_id, hashed key), as the snapshots are. Every write's filter names the _id and the shard key's two fields, so it routes to the one shard a key lives on, and the _id's uniqueness on that shard holds the key unique across the cluster.

A reserve or a confirm is a conditional upsert (see conditionalUpsert) whose filter admits only the key's owner or an expired pending reservation (a null expiry never passes $lte); a reserve's pipeline update keeps a confirmed reservation of the same owner as it is and adds the hold to its live pending one. Of concurrent reservations of a free key exactly one inserts it; the others hit the _id and then find it held. An abandon pulls its hold, then deletes the reservation only while it is pending, the owner's and without holds, so a hold added between the two keeps it. Expiry is judged by clock, not by the database's clock, so it behaves the same in memory and here.

Calls run on dispatcher, virtual threads by default.