Reliability model

Reliability model

Elah assumes that processes, disks, networks, and messages can fail independently.

Messages may be delayed, duplicated, reordered, or lost. A health check may be wrong. A process may stop without cleaning up. The design does not assume exactly-once delivery or graceful shutdown.

Core invariants

1. Every active cell has exactly one authoritative owner at one ownership epoch.
2. A stale writer is rejected rather than reconciled later.
3. Automatic failover waits for safe storage-level fencing.
4. Player transfers use stable identifiers and monotonically increasing state versions.
5. An authoritative copy is not deleted before a replacement is durably verified.
6. Ordinary gameplay traffic stays out of the control plane.
7. Normal Java clients remain normal clients.

Ownership uncertainty

A worker that stops answering may be dead, slow, or separated by a network partition. Assigning its cell immediately could create two writers.

The planned response is to keep ownership unavailable until storage-level epoch fencing can reject the old worker.

Transfer recovery

Player handoff is planned as an idempotent transaction. Repeating the same transfer must not duplicate effects. A target cannot activate stale state, and a recovered source must be fenced after ownership commits elsewhere.

Migration recovery

Cell migration is planned as ordered, recorded stages. Rollback is allowed before the ownership epoch commits. After that commit, recovery moves forward to one deterministic result.

Storage safety

The source remains authoritative until a replacement has been copied, durably synchronized, checksummed, manifested, independently verified, and optionally restore-tested.

Elah prefers a visible interruption over hidden corruption.