Ownership Models: Who Controls What, and When?

James C. Davis

2.4 Ownership Models: Who Controls What, and When?

Concurrent autonomous workers make runtime ownership unusually important. It is not enough to know which service owns a responsibility. When several workers may encounter the same work, the system must also represent who currently holds a claim, and when that claim ceases to matter. MAGE treats ownership across time as a distinct model class.

DocAble represents work that has been claimed but not yet completely merged using an in-flight lease. At the model level the important facts are few: the work item, its current owner, an epoch that distinguishes one claim from another, the lifetime of the lease, and release or reclamation.

MODEL CARD
In-flight lease · Ownership

Engineering question — Who currently appears to own this work, and when may the system treat that ownership as stale?
Model — a lease over a work item: an owner, an epoch, a lifetime, and the transitions claim → release and expire → reclaimable.
Property — each claim has an identifiable owner, epoch, and lifetime; an expired claim can be distinguished from a current one and reclaimed.
Quality attribute — liveness, crash recovery, and progress under contention.

Figure 2.4-1 draws the resulting ownership model. A claim installs an owner, an epoch, and a lifetime; a merge releases it; expiry makes the work reclaimable. The representation suppresses the machinery that realizes ownership — it need not describe Redis operations, database transactions, worker processes, broker delivery, or merge implementation to answer who currently appears to own this work, and when may the system treat that ownership as stale?

Figure 2.4-1. In-flight ownership model. A current claim records owner, epoch, and lifetime. Merge releases the claim; expiry makes it reclaimable. The model distinguishes a live claim from a stale one without representing the storage machinery that implements the lease.

The model also exposes an important distinction. The lease helps the system represent active ownership and recover work whose apparent owner has disappeared. It is not the final authority for performing a consequential side effect. Durable compare-and-set logic underneath the lease prevents a stale claimant from repeating an already-authorized effect. A slow worker may therefore lose its lease and cause the work to be redelivered without allowing the new claimant to repeat an already-authorized effect.

The difficult ownership failures do not necessarily appear in any one transition. They emerge from interleavings. Suppose one worker holds epoch 7, appears stale, and is reclaimed; another worker receives epoch 8; then the original worker wakes and attempts a late release using its old claim. Every individual action may be locally reasonable. The engineering question is whether their composition can destroy the current owner's lease or otherwise leave the system in an invalid state.

The ownership model reduces that question to a finite state space: owner, epoch, lifecycle state, reclaim, and release are the relevant variables and moves. The implementation may involve databases, queues, Lua, workers, and timers, but those details need not all enter the model. The reduction lets us explore directly the interleavings that can preserve or violate the ownership property. Figure 2.4-2 follows one such sequence to the fork an epoch fence closes.

Figure 2.4-2. Why ownership becomes an interleaving problem. Reclaim and reissue can overlap a stale holder's late release. An epoch fence makes the old holder's release inapplicable to the current claim.

Recovery is not permission. That distinction will matter in Part III: the same represented state can support different authority decisions.

The lease also shows that model classes overlap. Active leases can be counted to estimate demand, so the same representation contributes to an ownership question — who controls this work? — and a measurement question — how much work is genuinely in flight? Figure 2.4-3 draws that overlap: one represented fact fanning out into ownership, behavioral, and measurement views. The categories in this Part classify engineering questions, not mutually exclusive data structures.

Figure 2.4-3. Model classes overlap. The same lease state supports ownership, behavioral, and measurement questions. The classes distinguish purpose, not storage objects.

The next chapter turns from who holds the work to who is permitted to act — the declared decisions a system makes about which of its parts may reach which.