Persistence write behind

The write-behind queue: how an owner's database work is ordered, applied, retried and answered. The schemas it writes are on Persistence schemas, and why no owner touches the database on Persistence.

Work and its keys

An owner hands the queue a piece of work and gets a completion message back on its own thread.

Rule	Holds
Every piece of work names its keys	An account, a character, an email, or a named line such as the audit's
One line per key	All lines in one arrival order; a piece of work runs once it's first in every line it names
So	Work on one key runs one at a time and in order, work on different keys runs side by side, and work across several keys can't deadlock

Outcomes

Outcome	What happens
Committed	The owner hears back once the transaction commits
Refused	A write that breaks a unique rule, such as an email or a name already taken, completes as refused with the rule's name and isn't retried; the owner turns it into the client's answer
Failed	Retried, never dropped, at a delay that starts at FirstRetryDelay and doubles up to MaxRetryDelay, holding its keys meanwhile
The database unreachable	Persistence is marked unavailable until the next commit. While it is, logins are refused, and server status says so

A save worker applies each piece of work in one transaction, and SaveWorkers of them run at once.

Known edges

• A piece of work that fails for a reason other than the database retries forever, holding its keys, so it blocks its account until the fault is fixed. Whether to retry only failures that can pass later is an open question.
• Merging a newer save into a waiting one is built and tested, but no work uses it yet.
• The retry and worker settings are checked by the host's validation only.

Where the code lives

Piece	Path
The write-behind queue	Source/NexusTomorrow.Persistence/WriteBehind/
Tests	Tests/NexusTomorrow.Persistence.Tests/