BASE

BASE stands for:

1. Basically Available: The system guarantees availability of the data even during partial system failures.
2. Soft State: The system state may change over time due to eventual consistency and ongoing background processes.
3. Eventual Consistency: Given enough time, the system will reach a consistent state.

BASE is an approach often used in distributed systems where strict consistency is sacrificed for scalability, availability, and fault tolerance. It is the opposite of the ACID properties seen in traditional relational databases.

---

Comparison: BASE vs. ACID

Property	ACID	BASE
Focus	Consistency and correctness	Scalability and availability
Consistency Model	Strong consistency (immediate)	Eventual consistency (delayed)
Availability	May trade availability for consistency	Prioritizes availability over consistency
State	Hard state (fixed until explicitly changed)	Soft state (may change in the background)
Transactions	Supports multi-step, atomic transactions	Limited transaction guarantees
Use Case	Banking, financial systems	Distributed systems, big data applications

Implementation Examples

• DynamoDB:

  • Consistency Model: DynamoDB supports eventual consistency by default but offers strong consistency as an option.
  • Replication: Data is replicated across multiple nodes in different regions.
  • Conflict Resolution: Uses techniques like vector clocks or last-write-wins to handle conflicts.
  • Example:
    • A distributed system allows users to edit documents simultaneously, resolving conflicts later.

• Cassandra:

  • Writes are partitioned using consistent hashing.
  • Tunable consistency levels allow you to balance consistency and availability (e.g., QUORUM, ALL, ONE).

---

A Base e-Commerce

Scenario: Add an item to a cart while checking out.

• Steps:
  1. Write operation to indicate the item is added to the cart.
  2. Update inventory asynchronously.
• Challenges:
  • A brief period may exist where two users can purchase the last item simultaneously.
  • Conflict resolution: Eventually, one user will receive the item, and the other will be informed of the failure.
• Trade-offs:
  • Prioritizes availability (users can always interact with the system).
  • Accepts eventual consistency for non-critical operations like showing inventory counts.

---

BASE Techniques in Action

1. Replication:
   • BASE systems replicate data across nodes for availability.
   • Writes may propagate asynchronously to replicas.
   • Example: DynamoDB replicates data across multiple availability zones.
2. Partitioning:
   • Data is partitioned (sharded) across nodes to scale horizontally.
   • Example: Cassandra uses consistent hashing to distribute data.
3. Conflict Resolution

---

BASE Conflict Resolution Strategies

In BASE systems, conflict resolution is a critical mechanism for ensuring eventual consistency across distributed nodes. Common strategies include:

• Last-Write-Wins (LWW): Conflicting updates are resolved based on timestamps, with the most recent write considered authoritative. While simple, this can lead to data loss if earlier writes are overwritten unintentionally.
• Vector Clocks: Each node tracks a logical clock for its updates. Conflicts are detected when clocks are divergent, allowing the system to either merge changes automatically or defer to application logic.
• Application-Specific Logic: Developers define domain-specific rules for merging conflicts, such as summing values or prioritizing certain updates.
• Operational Transforms (OT): Often used in collaborative systems, OT ensures concurrent edits are transformed into a consistent order, enabling conflict-free merging.

---

How DynamoDB and Cassandra Implement BASE

DynamoDB achieves BASE by using a partitioned and replicated architecture. Data is distributed across partitions using consistent hashing, and replicas in multiple availability zones (AZs) ensure durability. Conflict resolution typically relies on LWW or user-defined logic for conditional updates. Eventual consistency is the default, but strong consistency can be requested for reads.

Cassandra, on the other hand, partitions data across nodes using consistent hashing and replicates each partition to a configurable number of nodes (replication factor). Write operations are coordinated by a leader node for each partition, with tunable consistency levels (e.g., ALL, QUORUM, ONE). Conflicts are resolved using LWW at write time, but developers can also implement custom resolution during read-repair operations or via periodic anti-entropy processes.