Why Consistency Is a Luxury: A Practical Guide to BASE Theory in Distributed Systems

Why Consistency Is a Luxury

On 2023 Double‑11 at midnight, Taobao processed 544,000 order‑creation requests per second, and on Chinese New Year’s Eve, WeChat red packets were sent and received billions of times within a few hours. Under such load, database connection pools are exhausted, caches are broken, and inter‑node synchronization latency jumps from milliseconds to seconds.

At that moment the system cannot guarantee both "absolute consistency" and "always‑on service" simultaneously; architects must choose. Enforcing consistency means waiting for all nodes to synchronize, slowing or timing‑out responses, while prioritising availability tolerates temporary data divergence.

Distributed‑System Fundamentals

A distributed system consists of multiple computers working together, with data stored across nodes and communication over a network. It has three unavoidable traits:

No shared architecture : each node runs independently without shared memory or disk.

Independent failures : a single node crash does not bring down the whole system, but failures can occur at any time.

Unpredictable network latency : communication delay depends on distance, bandwidth, and congestion.

Because a single machine cannot handle Double‑11‑scale traffic, the internet‑scale solution is inevitably distributed, but this brings the consistency challenge: data is spread across nodes, making it hard to ensure every node sees the same view.

CAP Challenges

Consistency (C) : all nodes see the same data at the same time.

Availability (A) : every request receives a non‑error response within a reasonable time.

Partition tolerance (P) : the system continues operating despite network partitions.

Partition tolerance is mandatory; therefore a system can only be CP (preserve consistency, sacrifice availability) or AP (preserve availability, sacrifice consistency).

CAP Theorem

In 2000 Eric Brewer conjectured that a distributed system cannot simultaneously provide consistency, availability, and partition tolerance. In 2002 Seth Gilbert and Nancy Lynch proved this mathematically, establishing the CAP theorem.

When a network partition occurs, consistency and availability cannot both be satisfied. A common misconception is that CAP forces a static "choose two out of three" trade‑off. In reality, when no partition exists, a system can provide both consistency and availability; only during a partition must it pick between C and A. For example, ZooKeeper offers both consistency and availability under normal operation but switches to CP mode during a partition, sacrificing some availability to maintain data consistency until the partition heals.

Most internet‑scale services adopt the AP approach, valuing availability over strong consistency because "service outage" is a higher cost than "temporary data inconsistency". Financial systems, however, tend toward CP, where "incorrect data" is more disastrous than slower responses.

Introducing BASE Theory

In 2008 Dan Pritchett published "BASE: An Acid Alternative" in ACM Queue, distilling practical engineering guidance for large‑scale internet systems. BASE addresses the key question: after abandoning strong consistency, how can a system remain trustworthy?

Basically Available (B) : core functionality stays available during failures; non‑core features may be degraded. Examples include e‑commerce platforms disabling product recommendations, delaying shipment notifications, or pausing review features during massive sales; China Railway's 12306 system queuing requests instead of processing them instantly; Netflix's Hystrix circuit breaker returning degraded responses for non‑core services to prevent cascading failures.

Soft State (S) : the system permits intermediate states where replicas temporarily differ. DNS illustrates this: after updating a record, global caches may take up to 48 hours (TTL) to reflect the change, so users in different regions can see different results. Social platforms also exhibit soft state when a post appears instantly in one data center but takes a few seconds to propagate to another.

Eventually Consistent (E) : after updates stop, the system guarantees that data will converge to a consistent state, though the convergence time varies. Variants include causal consistency, read‑your‑writes, session consistency, and monotonic reads.

ACID vs BASE Comparison

Consistency model : ACID – strong consistency; BASE – eventual consistency.

Data state : ACID – data is always consistent; BASE – intermediate states are allowed.

Typical scenarios : ACID – financial transactions, inventory deduction; BASE – social feeds, search index updates.

Performance cost : ACID – high (locks, synchronous waits); BASE – low (asynchronous replication).

Typical systems : ACID – MySQL, PostgreSQL; BASE – Cassandra, DynamoDB.

Failure recovery : ACID – rollback to a consistent state; BASE – accept inconsistency and repair asynchronously.

ACID and BASE are not opposing tools; they are chosen based on the workload, just like selecting a hammer or screwdriver for a specific job.

Choosing the Right Consistency Level

The core logic is to evaluate the cost of data inconsistency for your business.

CP‑preferred scenarios : financial transactions (incorrect balance means real loss), inventory deduction (overselling leads to loss or breach), core order status (inconsistent status causes duplicate or missed shipments). In these cases, data errors are far more severe than slower service.

AP‑preferred scenarios : social timelines (a few‑second delay is acceptable), search index updates (users rarely notice a slight lag), CDN cache refreshes (static resources can be stale briefly), comment systems (a short delay is tolerable). Here, service unavailability is more disruptive than temporary inconsistency.

Mixed strategy : different modules within the same system adopt different consistency levels. Taobao's Double‑11 is a textbook example: core transaction paths (order placement, payment) use strong consistency; comments and recommendations use eventual consistency; non‑core services are degraded in priority order to preserve the core.

Real‑World Cases

Amazon DynamoDB offers tunable consistency: eventual consistency reads are default and cheap, while strong consistency reads cost twice as much, prompting engineers to consider whether strong consistency is truly needed.

eBay architecture evolution : Dan Pritchett described eBay's gradual shift from a strong‑consistency architecture to an eventual‑consistency one for non‑core modules, achieving several‑fold throughput gains while keeping the core transaction path strongly consistent.

Taobao Double‑11 degradation strategy : multiple degradation layers are pre‑configured—product recommendation, delayed shipment notifications, paused review features, and reduced search filters. The core transaction flow remains strongly consistent; peripheral services are degraded according to priority, ensuring the system stays fundamentally available under extreme pressure.

Takeaway

BASE is not "giving up consistency"; it is "strategically compromising" by selecting the appropriate consistency level for the right time and scenario. Understanding the trade‑offs behind CAP and BASE equips architects to make informed decisions across micro‑service boundaries, cache strategies, technology selection, and team responsibilities.

For deeper insight, read:

Eric Brewer’s original CAP talk: "Towards Robust Distributed Systems" (PODC 2000).

Dan Pritchett’s BASE article: "BASE: An Acid Alternative" (ACM Queue 2008).

Amazon DynamoDB documentation on "Read Consistency".