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 ): a distributed key-value store where every read explicitly declares the consistency level it needs via a request header.

What it is under the hood:

Raft consensus via Raftly : a production-grade Raft library I built separately (see here ), covering leader election, log replication, pre-vote, fast log backtracking, and WAL-backed…