Eventual Consistency
An update is accepted now but reaches caches, replicas, search, or partner systems later, so brief stale reads are expected.
See it
What it is
Eventual consistency means an accepted update can become visible in connected systems at different times. The primary database may have the new value while a cache, search index, replica, or partner API still shows the old one. If updates stop and delivery keeps working, those copies are expected to converge. Werner Vogels' essay 'Eventually Consistent' is what put the term in general circulation.
Reach for this tradeoff when work can move asynchronously and brief staleness is cheaper than making every write wait for every downstream copy. DynamoDB, for example, offers eventually consistent reads, and reads from its global secondary indexes are always eventually consistent. User interfaces should acknowledge the accepted write and show a pending state instead of pretending every projection changed atomically.
Eventually is not a deadline. Without monitoring, a broken consumer can turn seconds of expected lag into permanent drift. Define a measurable lag target, carry a version through events, ignore updates older than the version already applied, and reconcile periodically. Do not use a stale projection to make a decision that requires current truth, such as whether inventory or account balance is available.
Ask AI for it
Make this PostgreSQL-to-OpenSearch projection explicitly eventually consistent. Write domain changes and an outbox row in one PostgreSQL transaction, publish the outbox asynchronously, and include a monotonic record version in every event. Make the OpenSearch consumer idempotent, reject versions older than the indexed version, retry transient errors with exponential backoff, and route exhausted events to a dead letter queue. Return a pending projection status after writes, expose current lag in seconds, alert when it exceeds 60 seconds, and add a nightly reconciliation job.