BASE: Trading Consistency for Availability
BASE is a database design philosophy that prioritizes availability over strict consistency, the opposite of ACID. It's used in large-scale systems like social media where uptime is key and slightly stale data is okay.
Why it exists
Traditional ACID databases struggle to scale horizontally while maintaining both high availability and strict consistency. For massive, distributed systems that serve millions of users, being unavailable is often worse than being slightly out-of-sync. BASE provides a framework for building systems that can handle this reality by relaxing consistency guarantees.
The mental model
Think of BASE like a group collaborating on a document in a shared folder without a central lock. Everyone can always open a version of the document (Basically Available), but their local copy might be slightly different from others' until changes sync up (Soft State, Eventual Consistency). This is more resilient than everyone waiting in line to check out the single "master" copy, which is the ACID approach.
How it works
BASE is an acronym for three properties:
Basically available
The system guarantees it will respond to a request. It prioritizes uptime, even if the response is stale data or a message indicating a failure, rather than being completely unresponsive.
Soft state
The state of the system may change over time, even without direct user input, as updates propagate through the distributed nodes. The system's state is not rigid and is always in flux until it reaches consistency.
Eventual consistency
This is the core promise. If no new writes are made to a piece of data, all replicas will eventually converge to the same value. It makes no guarantee about how long this will take.
When to use it
Use BASE for systems that need massive scale and high availability, and can tolerate some data staleness. This is common in social media feeds, user profile views, product recommendations, and large-scale analytics systems. The key is that the business logic can handle temporary inconsistencies without failing.
When not to use it
Do not use BASE for systems requiring transactional integrity and immediate consistency. Core banking systems, payment processing, and real-time inventory management are poor fits. Any operation where a user action must be reflected immediately and accurately for all subsequent operations should use a stronger consistency model like ACID.
One canonical example
A social media "like" count. When a user likes a post, the system can immediately update the count for that user (Basically Available) and then propagate that "like" to other replicas in the background. For a short time, other users might see an old count (Soft State). Eventually, all users will see the updated count (Eventual Consistency). This is acceptable because an exact, real-time like count is not critical to the user experience.
Interview question
When designing a large-scale distributed system, which factor would most strongly lead to choosing a BASE-compliant database over an ACID-compliant one?
- a.Ensuring all transactions are immediately and fully committed across the system.
- b.Guaranteeing strict isolation for concurrent operations to prevent data corruption.
- c.Prioritizing continuous system uptime even if data is temporarily inconsistent.Correct
- d.Maintaining a rigid, unchanging state until direct user input modifies it.
Why? this is the answer
The correct answer is B because BASE prioritizes continuous availability and responsiveness, even if it means data might be temporarily inconsistent. Option A describes a core tenet of ACID, which guarantees immediate, full commitment of transactions, often at the expense of availability in distributed systems.
Just read this? Test yourself on what you have been reading.
Read the original → geeksforgeeks.org
- #database
- #distributed systems
- #consistency models
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on database — each one lists the topics its interview covers.
See open roles