Money Has One Active Holder, Decided by the Database

Context

Competing preparation must not count the same effect or payout twice.

Decision

Use database uniqueness for exclusive active holdings, with row locks and versions on participating financial commands.

Alternatives Considered

Check availability only in application logic. Two competing requests can both pass an unlocked check.

Require serializable isolation for all preparation. The current implementation has no general serialization-retry protocol and already uses explicit locks and constraints.

Consequences

Conflict responses identify the existing holder where the service maps that race. Released holding rows remain outside the active unique index as history. Ancillary unversioned commands retain narrower protections than financial versioned commands.