BASE & Eventual Consistency
The NoSQL counter-philosophy: Basically Available, Soft state, Eventually consistent — trade strong guarantees for availability and scale.
What it is
BASE describes systems that prioritize availability over strong consistency. 'Basically available' means the system always responds, even with stale or partial data. 'Soft state' means the system's state may change over time without input, as replicas converge. 'Eventually consistent' means that given no new writes, all replicas will eventually return the last written value — but there's no bound on 'eventually', and reads in the meantime may return stale or out-of-order values. It's the explicit opposite of ACID.
Why senior interviewers ask
Senior interviewers want to know if you understand that 'eventually consistent' is a real engineering tradeoff with business consequences — not just a marketing word. The follow-up is always 'what does your app do when a user sees stale data?'
Key points
- Eventual consistency has no time bound — could be milliseconds or hours under partition.
- Stronger variants: read-your-writes, monotonic reads, causal consistency — useful intermediates.
- Conflict resolution strategies: last-write-wins (LWW), CRDTs (Conflict-free Replicated Data Types), vector clocks, application merge.
- Anti-entropy: background processes (Merkle trees, read repair, hinted handoff) reconcile divergent replicas.
- Common in leaderless systems (Dynamo, Cassandra, Riak) where any node can accept writes.
- Business logic must tolerate stale reads — show 'pending', use idempotency keys, model state as commutative.
Real systems
Interview probe
'A user updates their profile and immediately reloads — they see the old name. What do you do?' Answer: read-your-writes consistency (route reads to the leader for that user briefly, or use a session token that tracks the write timestamp). Don't just hand-wave 'eventually consistent' and move on.