Strong versus eventual consistency in NoSQL

WHAT THIS TESTS The interviewer wants to see that you treat consistency as a tunable tradeoff, not a binary right-or-wrong setting, and that you can map it to business requirements.

A GOOD ANSWER COVERS A distributed database stores copies of each item on multiple nodes. Strong consistency means a read is guaranteed to reflect the result of all writes that completed before it; achieving this requires the system to coordinate or wait for replicas, which adds latency, reduces availability during a partition, and in DynamoDB consumes twice the read capacity of an eventually consistent read. Eventual consistency means a write propagates to replicas asynchronously, so a read right after a write might return a slightly stale value, but reads are faster, cheaper, and remain available even when nodes are unreachable. Cosmos DB exposes a spectrum between these extremes, including bounded staleness, session, and consistent prefix, letting you trade precisely. The right mental model is a dial: the more guarantees you demand about reading the latest write, the more coordination, latency, and cost you pay, and the less available the system stays when nodes cannot reach each other, so you tune the dial per access pattern rather than picking one global setting.

COMMON WRONG ANSWERS Describing eventual consistency as data corruption or a failure mode. Insisting strong consistency should always be used; it raises cost and hurts availability and is often unnecessary. Ignoring that the choice affects capacity, latency, and partition behavior.

LIKELY FOLLOW-UPS What intermediate models exist and what does bounded staleness guarantee? How does the choice interact with the CAP theorem during a partition? How does read-your-own-writes differ? What is the cost difference in DynamoDB?

ONE CONCRETE EXAMPLE For an account balance before authorizing a withdrawal you demand strong consistency, because reading a stale balance could allow an overdraft. For a social feed like-count you accept eventual consistency, because showing 1,204 likes instead of 1,205 for a few seconds is harmless and the cheaper, faster, always-available read is the better engineering choice.