What are eventual consistency and the BASE model?

WHAT THIS TESTS This checks whether you understand the availability-favoring consistency model and, crucially, whether you can decide per feature where staleness is acceptable and where it is dangerous.

A GOOD ANSWER COVERS Eventual consistency guarantees that if no new updates are made, all replicas will eventually converge to the same value; it does not bound how long convergence takes, and reads in the meantime may be stale. BASE stands for Basically Available, Soft state, and Eventually consistent, the philosophy many distributed NoSQL systems adopt as an alternative to ACID. It prioritizes availability and partition tolerance, accepting temporary divergence. The art is matching the model to the feature. For tolerant features, a view count, a like total, a follower list, or a social feed can be briefly stale without user harm. For strict features, a bank account balance, a payment or transfer, decrementing limited inventory, or booking a unique seat demands strong consistency, because a stale read can let two users buy the same last item or overdraw an account.

COMMON WRONG ANSWERS Describing eventual consistency as simply slower strong consistency, or implying convergence is instant. Treating BASE as universally better than ACID rather than a different trade-off. Applying eventual consistency to monetary or uniqueness-critical operations, which invites double-spend and oversell bugs.

LIKELY FOLLOW-UPS How do you resolve conflicting concurrent writes? What are read-your-writes and monotonic-read session guarantees? How do quorum reads and writes tighten consistency? Where does this sit relative to CAP?

ONE CONCRETE EXAMPLE A tweet's like counter can lag by a few seconds across regions with no real consequence, a fine fit for eventual consistency. By contrast, transferring money between two accounts must be strongly consistent and atomic so the system never shows or permits a balance that double-counts or goes negative.