Quorum tuning for write availability
A session/feature-flag store backs auth for a 200M-user product; it is replicated N=3 and the team currently requires W=3 (write all replicas) for safety, which means a single slow or down replica makes writes fail and users can't log in. They want writes to stay available when one replica is temporarily unreachable, without silently dropping the write or letting a read return a value that was never durably stored. Walk through quorum tuning (N/R/W), sloppy quorum + hinted handoff, and read repair, and be explicit about exactly what consistency guarantee each choice gives — including whether R+W>N actually guarantees you read the latest write here, and the failure modes the team is exposing themselves to.
Clarify scale and constraints first. Propose a clean component breakdown, then go deep on the hard parts (data model, bottlenecks, consistency, failure modes) and name the trade-offs you are making.