This document records the main external ideas influencing AllocDB's design.
Why it matters:
- explicit bounds
- deterministic execution
- strong assertion culture
- minimal dependencies
- small trusted core
Sources:
Why it matters:
- replicated state machine model
- deterministic log application
- view change and recovery structure
Source:
Status in AllocDB:
- conceptually relevant
- deferred until
replication.md
Why it matters:
- quorum-shape flexibility
- better framing for future replication tradeoffs
Source:
Status in AllocDB:
- deferred until replication work begins
- tracked in
replication.md
Why it matters:
- storage recovery should use protocol knowledge
- corruption handling must be explicit
Source:
Status in AllocDB:
- informs
fault-model.mdandstorage.md
Why it matters:
- local durability assumptions are weaker than many systems assume
- fsync failure must be part of the design, not an afterthought
Source:
Status in AllocDB:
- informs fail-closed storage handling
Why it matters:
- real code under deterministic simulation
- seeded, reproducible fault injection
Source:
Status in AllocDB:
- informs
testing.md
Why it matters:
- single control thread
- design away invalid states
- random fault testing
Source:
Status in AllocDB:
- informs
principles.md,semantics.md, andtesting.md
Why it matters:
- exposes client-visible ambiguity under fault
- pushes the design to distinguish definite and indefinite outcomes
- reinforces the need for explicit retry semantics instead of vague "exactly once" claims
Source:
Status in AllocDB:
- informs
semantics.md,fault-model.md, andtesting.md
These references are design inputs, not cargo cult requirements.
AllocDB should adopt the underlying discipline:
- deterministic state machines
- explicit fault models
- boundedness
- replayable recovery
- testability under injected failure
without copying distributed features into v1 before the single-node allocator is correct.