Scalability
Consistency
The guarantee that reads reflect the most recent writes. Models span a spectrum from strong (always current, but costly to coordinate) to eventual (replicas converge over time, cheap and highly available). Choosing a model is choosing a trade-off: strong consistency simplifies reasoning but limits availability and adds cross-region latency.
Purpose
Consistency is the guarantee about what reads see relative to writes. Strong consistency means every read reflects the latest write, as if there were one copy of the data; eventual consistency means replicas converge given time, and a read may briefly see the past. Between them lie useful models like read-your-writes and causal consistency.
When to Use It
Strong consistency where correctness is absolute — balances, inventory counts, uniqueness checks. Eventual consistency where staleness is invisible or harmless — feeds, view counters, caches, search indexes. Most real systems deliberately mix both.
Trade-offs
Strong consistency requires coordination — quorums, consensus — which costs latency and, under partition, availability (the CAP trade). Eventual consistency is fast and resilient but pushes complexity up into the application: reconciling conflicts, tolerating anomalies, explaining oddities to users.
Implementation
Classify each data type by the anomaly it can tolerate, then choose storage modes accordingly: transactions or quorum operations for the critical path, async replication elsewhere. Engineer around the seams — session pinning after writes, idempotent updates, conflict resolution rules (last-write-wins is a choice, not a default).