Eventual consistency
Database copies may briefly disagree after a write, but they should settle on the same state once updates finish spreading.
See it
What it is
Eventual consistency means copies of data are allowed to disagree for a while after a write. The primary can accept a change before every replica has applied it, so two reads made at the same moment can return different answers. If writes stop and replication continues, the copies should converge on the same state.
Reach for it when lower write latency and availability matter more than showing every reader the newest value immediately. Amazon CTO Werner Vogels put the phrase into wide circulation with his 2008 essay Eventually Consistent. DynamoDB uses eventually consistent reads by default, and asynchronously replicated SQL databases make the same tradeoff. It works well for feeds, analytics, and other screens where a short delay is tolerable.
Gotcha: eventual says nothing about how long convergence takes. Replica lag can turn a harmless delay into missing inventory, duplicate work, or a confusing save-then-refresh experience. Measure lag, define a maximum, and route correctness-sensitive or read-your-writes traffic to the primary.
Ask AI for it
Design this read path for PostgreSQL asynchronous streaming replicas. Send writes and correctness-sensitive reads to the primary, allow stale catalog and reporting reads on replicas, and preserve read-your-writes for 30 seconds after a mutation by pinning that user to the primary. Measure replica delay with pg_last_xact_replay_timestamp(), stop routing to any replica more than 10 seconds behind, expose lag and routing metrics, and add tests for delayed replay, replica failure, and recovery.