Eventual Consistency

Key features

• Replica lag: a replica applies a primary's writes asynchronously, so it can be milliseconds to seconds behind depending on write volume — a read routed to a lagging replica sees the previous state, not the latest one (the exact mechanism the replication-lag concept covers in depth)
• Queue/message propagation delay: a message published to a queue is not instantly visible everywhere — a consumer has to receive and process it, and different consumers (or consumer groups) can be at different points in that processing at any given moment
• Independent caches: two services that each cache the same underlying entity, refreshed on their own separate schedules or triggers, can each be correctly serving a snapshot from a different point in time
• This disagreement is bounded, not permanent — the defining property of "eventual" consistency is that the system converges once writes stop, distinguishing it from a system that would simply diverge and never agree
• The disagreement window is a real, measurable quantity (often called the "inconsistency window" or "staleness bound"), not an unknowable black box — it can be monitored and, for many systems, bounded with an explicit maximum

Signature

disagreement is temporary and structural — propagation takes real time, but the system provably converges

Key features

• Eventually-consistent-acceptable workflows share a pattern: the cost of acting on stale data is small, temporary, and usually self-correcting on the next read — like counts, view counts, "last seen" timestamps, search index freshness, recommendation feeds
• Strong-consistency-required workflows share the opposite pattern: acting on stale data can cause an irreversible, costly, or safety-critical mistake — account balances, inventory reservations that prevent overselling, anything enforcing a uniqueness or limit invariant (one account per email, no double-booking a seat)
• The same underlying data can need different consistency for different reads of it — an account balance shown on a dashboard (eventual is fine, it is informational) versus the same balance checked at the moment of an actual withdrawal (must be strongly consistent, it is enforcing a real constraint)
• Strong consistency has a real, unavoidable cost: more coordination between nodes, generally higher latency, and reduced availability during a network partition (the system may have to refuse an operation rather than risk an inconsistent result) — this cost has to be worth paying for the specific workflow, not assumed free
• A useful test: ask "what is the worst realistic consequence if this specific read is 5 seconds stale?" — if the honest answer is "nothing a user would notice or that costs the business anything," eventual consistency is very likely fine; if the answer involves money, safety, or a broken invariant, it very likely is not

Signature

ask: what is the real cost if THIS read is 5 seconds stale? — decide per workflow, not system-wide

Key features

• An explicit state field (e.g. status: "pending" | "processing" | "complete" | "failed") turns an invisible asynchronous gap into a visible, queryable fact instead of an implicit, undocumented assumption
• Without an explicit status, a caller has no way to distinguish "still processing, be patient" from "silently failed, will never complete" from "actually already done, but this specific read is stale" — three very different situations that look identical without an explicit signal
• A well-designed state machine names every real outcome, not just the happy path — pending, processing, complete AND failed/cancelled/expired, so a caller can build correct handling for every state rather than assuming "not complete yet" always means "still in progress"
• Explicit status pairs naturally with polling or a push mechanism (webhook, WebSocket, SSE) so a caller does not have to guess when to check again — the status itself, or a change notification, drives the next action
• This pattern directly prevents a common asynchronous-workflow bug: a caller that assumes "I submitted this, so it must be done by the time I check again a moment later" and acts on an assumption instead of an actual observed state

Command

{
  "orderId": "ord_123",
  "status": "processing",
  "statusHistory": [
    { "status": "pending", "at": "2026-08-22T10:00:00Z" },
    { "status": "processing", "at": "2026-08-22T10:00:02Z" }
  ]
}