A consistency model where reads may see stale data briefly, but all replicas converge given enough time without writes.
Eventual consistency is a guarantee, common in distributed databases (DynamoDB, Cassandra, S3), that all replicas of a piece of data will become identical given enough time and no new writes. The tradeoff: you lose strong read-after-write consistency in exchange for higher availability and lower write latency, especially across regions. CAP theorem makes you pick: under partition, you choose either consistency (CP, e.g. CockroachDB defaults) or availability (AP, e.g. Cassandra).
Most outages in distributed systems are eventually-consistent stores behaving exactly as designed: a write happened in us-east, a read landed in us-west milliseconds later, the read got stale data, the user logged a bug. Treating that as 'a bug' instead of 'a system property' wastes engineering time. Naming the model lets you debug it.
See the part of the platform that handles eventual consistency in production.