Eventual consistency

Where it shows up in real systems

• Key-value store

  Data is spread across partitions by the hash of its key, so throughput scales almost without limit as long as keys are well distributed. A single very popular key hits one partition's limit and gets throttled. On-demand mode follows traffic but absorbs sudden jumps above twice the previous peak with throttling.

  In production: Amazon DynamoDB, Azure Cosmos DB, Google Bigtable, Riak, FoundationDB

• Document database

  A replica set elects a new primary when the current one fails. With write concern majority, an acknowledged write survives that failover; with w:1, recent writes can be rolled back. Reading from secondaries scales reads but returns slightly stale data.

  In production: MongoDB Atlas, Amazon DocumentDB, Couchbase, Firestore

• Search engine

  Documents become searchable after the next refresh, so search is eventually consistent with your primary database. Queries are CPU-heavy; add nodes and replicas for throughput, and keep the source of truth elsewhere.

  In production: Elasticsearch, OpenSearch, Apache Solr, Algolia, Meilisearch