What is eventual consistency?

Eventual consistency is a consistency model in distributed systems where, given enough time without new updates, all replicas of the data will eventually converge to the same value. It does NOT guarantee that all reads return the latest write immediately — there is a period of inconsistency after a write during which different replicas may return different values. Contrast with strong consistency: every read reflects the most recent write — reads may be slower (must check all replicas or wait for acknowledgment). Why eventual consistency? The CAP theorem shows that during network partitions, you must choose availability or consistency. AP systems (Cassandra, DynamoDB) choose availability — stay up and accept writes during partitions, with replicas syncing when the partition heals. This enables massive scale and global distribution. Examples of acceptable eventual consistency: social media likes/follower counts (stale by seconds is fine), DNS propagation (updates propagate over hours), shopping cart contents, collaborative document editing (eventually converges). Unacceptable for: bank balance (strong consistency needed), inventory count (must avoid overselling). Techniques for reading recent data in AP systems: read from multiple replicas and take the latest (quorum reads), or read from the primary. BASE model (Basically Available, Soft-state, Eventually consistent) contrasts with ACID as the philosophy behind eventual consistency systems.