In my preview.6 article, I wrote about what happens after a write is accepted: binary WAL frames, group commit, crash recovery, and durable retries. That work made the durability boundaries easier to name.
It does not answer the next uncomfortable question: what happens when the node should stop accepting more durable work?
A write-ahead log that never refuses appends will eventually fill the disk. A shared concurrency gate that never distinguishes callers will let one noisy tenant starve everyone else. From the outside, both failures can look like “the cache is down,” even while the process is still alive.
Those questions shaped 0.1.0-preview.7: journal disk quotas that reject durable writes with a stable error, and per-principal backpressure keyed by JWT subject (or connection id when there is no subject).
Squirix is still an experimental preview, not a production-ready cache. Its APIs and storage formats may change during 0.x. This article describes the current design and the reasoning behind it, not a compatibility promise.
