event-store-append-is-not-crash-consistent

Status: IN

Event store appends update in-memory state before persisting to disk with no rollback on failure, batch appends can leave partial writes, and the per-call file open/close pattern adds overhead without providing atomicity guarantees.

Justifications

Memory-first writes with no rollback plus non-atomic batch persistence equals inconsistency after any crash

Depends on (SL): event-store-memory-ahead-of-disk, persist-after-memory, batch-append-not-crash-safe, persist-event-per-call-open

Depended on by

JSON