THE CHALLENGE
What survives when a replica fails?
A successful transaction is only half the problem. A database also has to preserve its meaning when a primary disappears, a connection breaks, or a machine restarts with damaged storage. AegisDB brings these failure cases into the same testbed as the database itself.
ENGINEERING
Ordering writes and recovering durable state
The runtime uses Viewstamped Replication (VSR), with a serialized consensus actor in each daemon. Four native network threads and a separate disk worker handle I/O; C11 single-producer/single-consumer queues connect the work. The compiled daemon embeds CPython rather than running a separate Python service.
Transactions can combine pre-write reads, conditional expectations, and all-or-nothing writes. Reads and analytical queries join the replicated order. The query engine supports SUM, COUNT, MIN, MAX, and AVG using typed column chunks, selection vectors, and null bitmaps.
The storage path fsyncs checksummed WAL blocks before protocol acknowledgement. Checkpoints publish immutable SSTables through an atomically replaced CURRENT manifest. On restart, replicas load the tables and replay the WAL tail; detected corruption quarantines a node until quorum recovery.
Real failures, not only simulation
A supervisor drives five processes through SIGSTOP, SIGCONT, SIGKILL, directed partitions, disconnected sockets, corrupt frames, and a damaged SSTable. A separate deterministic simulator remains available for reproducible traces.
Retry without duplicate transactions
Client identity and increasing sequence numbers support deduplication. Recorded replay checks retry the original 5,000 requests and compare their results without adding duplicate commits.
Separate model proof from implementation evidence
Lean establishes safety of the VSR transition system. Runtime tests independently examine byte-level storage, networking, and recovery. Neither is presented as a substitute for the other.