Eventual vs Strong Consistency
Strong consistency guarantees that after a write, all subsequent reads see the new value. Eventual consistency guarantees that if no new writes occur, all replicas will eventually converge to the same value.
Strong consistency = a live scoreboard (always current). Eventual consistency = the morning newspaper (accurate, just a few hours behind). Both give you the final score -- the question is when.
Strong consistency requires coordination between replicas on every write — adds latency (at least one extra network round trip). Typically implemented via consensus protocols (Raft, Paxos) or synchronous replication. Eventual consistency allows lower write latency and higher availability — replicas accept writes independently and reconcile later. Conflicts are resolved by LWW (Last Write Wins using timestamps), vector clocks, or CRDTs.
Linearizability (the strongest consistency model) means operations appear instantaneous: if write W completes before read R begins, R must see W's value. Sequential consistency is slightly weaker: all operations appear in some sequential order consistent with each process's program order. Eventual consistency is the weakest: no guarantees about intermediate states, only eventual convergence. Read-your-writes consistency (session consistency) is a practical middle ground: a user always sees their own writes, even if other users see stale data. This is achievable by routing a user's reads to the replica that received their write or by using a sticky session. Monotonic reads consistency: once you read a value v, subsequent reads return v or a newer value — never an older value. This prevents a user from seeing a post disappear after seeing it.
I'd classify each data type by its consistency requirement. User account balance: strong consistency (linearizable). Shopping cart: session consistency (read-your-writes). Social feed: eventual consistency. For strong consistency, I'd use Raft-based stores (etcd, CockroachDB) or PostgreSQL synchronous replication. For eventual consistency, I'd choose a conflict resolution strategy upfront: LWW for simple overwrites, CRDTs for counters and sets that need safe merging.
Assuming eventual consistency means 'might never converge.' Real eventually consistent systems (Cassandra, DynamoDB) typically converge within milliseconds under normal conditions. The concern is the divergence window during failures and how your application behaves during that window.