Strong vs Weak Consistency Per Feature

Different features in the same system can have different consistency needs. Don't pay for strong where eventual is fine.

How It Works

A single product rarely needs one Consistency model throughout. Banking: account balance needs strong consistency (read-your-writes), but transaction history can be bounded-staleness (a few seconds lag is fine). Social media: likes count can be eventually consistent (off by 1 for 30 seconds is OK), but "block this user" must be strongly consistent (stale = security hole). Shopping: inventory count needs strong consistency at checkout (prevent overselling), but "related products" can be aggressively cached. The technique: per-feature consistency, deployed in the same data plane. In interviews, for any consistency-sensitive feature, state the specific invariant you're preserving and choose the weakest consistency that preserves it — don't default to strong for the whole system.

Real-World Example

Amazon DynamoDB exposes "eventually consistent" (default, cheap) and "strongly consistent" (2× read cost) as a per-request option. Their guidance: use strongly consistent reads for features where stale data is incorrect (balance displays, cart contents during checkout); use eventually consistent for features where stale data is just annoying (product pages with minor price lag). Cassandra similarly exposes per-request QUORUM vs ONE consistency. The pattern: give developers the knob per read, don't force one consistency level across the whole workload.