The write-ahead log: how the cache survives a kill -9

Caches traditionally shrug at durability, 'it's just a cache', but an LLM cache's contents cost real money to rebuild. Losing a warm corpus to a pod reschedule means re-purchasing it from your provider at full price. So CrowkisDB treats every entry as worth keeping: writes land in the write-ahead log before anything else, each record framed with a CRC32 checksum, fsynced according to policy.

Recovery is the payoff: on startup the engine replays the log from the last checkpoint, validating every checksum, rebuilding the memtable to the exact pre-crash state. A torn write at the tail, the classic power-cut artifact, fails its checksum and truncates cleanly instead of poisoning the replay. The vector index recovers alongside, so semantic search resumes where it stopped.

flowchart TD
  W["candidate write"] --> S1["coherence · 0.30"]
  S1 --> S2["content · 0.10"]
  S2 --> S3["source trust · 0.30"]
  S3 --> S4["isolation · 0.15"]
  S4 --> S5["neighbourhood · 0.15"]
  S5 --> G{"composite ≥ 0.75?"}
  G -- yes --> OK["accepted"]
  G -- no --> NO["refused + ledger entry"]
  style OK fill:#fbe9e8,stroke:#d62221,stroke-width:2.5px
  style NO fill:#f3eee5

We don't trust this machinery; we attack it. The integration suite kills the process mid-write and verifies every acknowledged entry survives; the Docker smoke test does the same to the whole container. Durability claims that aren't tested by murder are marketing.

#The bottom line

The result is operationally liberating: deploys, reschedules, and crashes are non-events. The cache you had is the cache you have. Boring, by design, provably.