ACID vs BASE is a false dichotomy: Why your system needs both

The architect’s dilemma

If you have ever designed a distributed system, you have faced the classic dilemma. On one side are the ACID principles with all that they bring, Atomicity, Consistency, Isolation, and Durability. This is the world of banks and monetary transactions, with tight security where data integrity is of paramount importance and every transaction guarantees meticulous precision. But this strong consistency comes at the cost of performance.

On the other side you have BASE (Basically Available, Soft State, Eventually Consistent). This is the world of social media feeds and high traffic websites with high availability and scalability. Here, strong consistency is reduced to eventual consistency where data will be consistent with comparable latency.

For years, architects have been told they must choose but one at the expense of the other. It is a compromise that feels like you are leaving value on the table either way.

The hybrid solution

A mature modern architecture should not force you to pick just one. Instead, it should recognize a platform with its entire complexity that an application is not a singular entity, rather, it’s a collection of different jobs. For instance, a payment service has different needs than a product catalog, as does an inventory service compared to a user profile service.

The solution to this, ideally in a distributed system with a microservices architecture, is to adopt a hybrid data strategy. Instead of a “one size fits all approach”, we can apply different data models to different parts of the application based on their requirement and business logic. We can achieve both strong consistency and high availability where they are needed in the microservices. This allows us to achieve perfect data integrity for critical operations while simultaneously delivering the high availability and performance the users expect for less critical operations.

A real-world blueprint on architecting for a global retailer

Consider a mid-sized global apparel company with branches in Europe, Asia and America and E-commerce presence in those continents, whose rapid growth outpaced their IT infrastructure, leading to a classic conflict between operational needs and customer experience.

They were facing two different demands, one no less important than the other.

1.Inventory accuracy

When a customer buys a pair of jeans online, the inventory system must be 100% accurate immediately across the globe. An error here could mean overselling stock, leading to order cancellations, with customer dissatisfaction and logistical catastrophes following soon after. This part of the business hence demands perfect precision.

1. Fast and engaging storefront

At the same time, customers browsing the website expect a fast, seamless experience. They would want to see product catalogs load instantly and their user profiles must be responsive all the time. This part of the business demands high availability and top-tier performance.

This is where a single, monolithic database begins to struggle. Forcing the entire system to operate with strict rules of the inventory makes the storefront less responsive just as well as letting the whole system abiding by the eventual consistency principles risks the integrity of financial and stock data.

The solution

First let us talk about the parts of the business that necessitate zero margin for errors, like inventory, orders and payments. This is the financial and logistical backbone of the company where an error is not just a bug, it’s revenue loss and customer dissatisfaction. The primary goal of such services is strong consistency. To this end, we use a synchronous multi-master replication strategy, a diplomatic choice that introduces both safety and reliability.

Now let’s break that down.

• Synchronous

When a transaction is processed, the transaction is not confirmed until every single regional database/node has received the update and acknowledged it. This guarantees strong consistency and is ACID-compliant. For instance, the inventory count would always be accurate across the globe at any given moment.

• Multi-master

Any regional node can accept writes (e.g., processing an order). This provides high availability and eliminates the single point of failure while ensuring that an outage in a regional node does not stop the entire company from functioning.

This approach is the digital equivalent of a bank transaction, built on ACID principles. To implement this, we could use a battle-tested relational database like PostgreSQL or a managed cloud service designed for the exact same purpose as Amazon Aurora. The trade-off is slight increase in write time but it’s a price worth paying to ensure security and accuracy.

Next, let’s talk about parts of the business that interact with customers directly like product catalogs, user profiles and recommendations. The primary goal of these services is to be fast, engaging and always online. To this end, we use an asynchronous, master-slave replication strategy.

Here’s what that means.

• Asynchronous

When a user updates their profile, the change is written to a primary master node, and a success message is immediately returned to the application layer. The update is then propagated to the rest of the read replicas in the background, without making the user wait (reduced latency).

• Master-slave

A single master database handles all writes, ensuring a simple, conflict-free process. Meanwhile, read-only slave replicas in other regions handle read requests that improves read speed and load balancing of read requests.

This approach leads to eventual consistency and is BASE-compliant. There might be a delay of few seconds before a change is globally visible which is an acceptable trade-off for a highly responsive platform. To implement this, we could use a database like MongoDB or a highly scalable cloud-based NoSQL database like Amazon DynamoDB or Cassandra.

The key takeaway — design with intent

For years, the debate between ACID and BASE has been viewed as a battle of principle. But as we have seen, the most effective solution is not about choosing a side, and it is not always about dichotomy but holism every now then. It involves recognizing that a complex system is not a monolith with a single set of needs but rather a diverse ecosystem with different business logic and functions with unique requirements.

The inventory system’s job is to be an infallible ledger while the product catalog’s job is to be fast and engaging. By using a hybrid strategy, we allow each part of our system to be excellent at its specific task, rather than forcing the entire system to settle for a “one size fits all” compromise.

Thus, the next time you are faced with architect’s dilemma, remember to design with intent. Analyze the business domain, understand the trade-offs and build a system that uses the right strategy for the right use case. The most resilient of systems do not choose a side. Instead, they build a bridge between them.