I built a distributed KV store where every read picks its own consistency level, MVCC engine, Raft consensus, 4 runnable production failure scenarios Most distributed systems discussions treat consistency as a single setting you set once at the architecture level and never touch again. "We use eventual for performance." "We use Postgres so everything is strong." One answer, applied to every read in the system. The problem is that a bank balance and a profile picture are not the same problem. A flight seat availability check and a "last seen 2 minutes ago" timestamp are not the same problem. One stale read causes a double booking. The other causes a millisecond discrepancy nobody will ever notice. I wanted to understand the *actual* cost — in `ops/sec` and stale-read percentages, not just in theory. So I built **kv-fabric** ([GitHub](https://github.com/ani03sha/kv-fabric)): a distributed key-value store where every read explicitly declares the consistency level it needs via a request header.…