Base Properties - Learning Module

Loading content...

0/273

When BASE is Acceptable

The Confidence to Choose BASE

Understanding BASE conceptually is one thing. Having the confidence to use it in production—knowing exactly when eventual consistency is safe—is another entirely. Engineers often default to ACID 'just to be safe,' leaving performance and scalability on the table. Others embrace BASE too eagerly, creating subtle bugs that surface only under specific conditions.

This page is your practical guide to BASE adoption. By the end, you'll have clear heuristics for identifying BASE-appropriate scenarios, real-world examples from companies operating at massive scale, and the confidence to make informed decisions about consistency in your own systems.

What You Will Learn

By the end of this page, you will understand the domain characteristics that make BASE acceptable, concrete use cases where BASE excels, scenarios where BASE is dangerous and should be avoided, risk assessment frameworks for borderline cases, and real-world case studies from Amazon, Facebook, Netflix, and others.

Domain Characteristics Favoring BASE

Certain domains and problem types are naturally suited to eventual consistency. Recognizing these characteristics helps you identify BASE opportunities without deep analysis.

Characteristics That Make BASE Safe

•Monotonic Operations — Values only increase (view counts, like counts, follower counts). Temporary undercounting is acceptable; eventual accuracy is fine.
•Idempotent Actions — Repeated operations have the same effect (setting a value, toggling a flag). Retries don't cause problems.
•Append-Only Data — Data is only added, never modified or deleted (logs, events, audit trails). Eventual replication is safe.
•Statistical Accuracy Sufficient — Exact values aren't required (analytics, recommendations, trending topics). Approximate is fine.
•User-Perceived Consistency — Inconsistency isn't visible to individual users (read-your-writes sufficient). Global consistency unnecessary.
•Self-Healing on Retry — Users naturally retry (page refresh, pull-to-refresh). Temporary inconsistency auto-resolves.
•Low Conflict Potential — Data is partitioned by user/tenant. Users mostly write their own data. Cross-user conflicts rare.

Domain Characteristic Assessment
Characteristic	BASE-Friendly	ACID Required
Value direction	Monotonic (only increases/decreases)	Arbitrary (can go up or down)
Update pattern	Set/replace	Increment/modify based on current
Conflict frequency	Rare (user-partitioned)	Common (shared resources)
User perception	Slight delay acceptable	Immediate visibility required
Error recovery	Simple retry	Complex rollback needed
Business impact	Cosmetic/UX	Financial/legal/safety

The 'Show Stale?' Test

A quick heuristic: 'If I show a user data that's 5 seconds old, what's the worst that happens?' If the answer is 'minor confusion' or 'they refresh,' BASE is probably fine. If the answer is 'they see wrong balance' or 'double-booking,' ACID is needed.

Concrete Use Cases Where BASE Excels

Let's examine specific use cases across different domains where BASE is not just acceptable but optimal.

Social Features

•Like/reaction counts — Showing '1.2K likes' vs '1.1K likes' for a few seconds doesn't matter. Users don't notice.
•Follower counts — '5.2M followers' vs '5.1M followers' is imperceptible. Eventual accuracy is fine.
•Activity feeds — Seeing a post 2 seconds late is invisible to users. Real-time isn't actually required.
•Comment threads — Comments appearing in slightly different order on different devices is acceptable.
•Notifications — A notification arriving a few seconds late is fine. Missing it entirely is not (durability matters).

Analytics and Metrics

•Page view counters — Dashboard showing 1.5M vs 1.4M views is statistically indistinguishable.
•Click-through rates — CTR of 2.3% vs 2.2% doesn't change decisions. Eventual accuracy fine.
•A/B test metrics — Tests run for days/weeks; eventual consistency over seconds is irrelevant.
•Trending topics — 'Currently trending' can be a few seconds behind. Freshness, not exactness, matters.
•Recommendation inputs — User behavior for recommendations can be slightly delayed.

E-commerce (Specific Operations)

•Shopping cart (browsing) — Cart should always be available. Reconcile on checkout. Lost availability = lost sale.
•Product catalog — Price/description changes can propagate in seconds. Users rarely notice.
•Reviews and ratings — A review appearing a few seconds later is fine. Average rating being slightly off is fine.
•Wishlist/saved items — User's personal data; no cross-user consistency needed.
•Recently viewed — Recommendation feature; eventual consistency is perfectly acceptable.

Content and Media

•Content delivery — CDN caches are inherently eventually consistent. TTLs handle freshness.
•User-generated content — Blog posts, videos, images. Visibility delay of seconds is imperceptible.
•Search indexes — Search results can be seconds behind writes. Users expect some delay.
•Media playback state — 'Continue watching' can be slightly behind. Resume position is approximate anyway.
•Collaborative editing — Tools like Google Docs use eventual consistency with operational transformation.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
// Like counter using BASE consistency
// Optimized for availability and speed, accepts eventual accuracy
 
class LikeService {
  private redis: Redis;          // Primary storage (fast, eventual)
  private postgres: PostgresDB;   // Source of truth (eventual sync)
  private eventQueue: EventQueue; // For durability
  
  async likePost(userId: string, postId: string): Promise<LikeResult> {
    const likeId = `like:${postId}:${userId}`;
    
    // Step 1: Check if already liked (fast, possibly stale)
    const alreadyLiked = await this.redis.sismember(
      `post:${postId}:likers`, 
      userId
    );
    
    if (alreadyLiked) {
      // Idempotent - return success even if duplicate
      return { success: true, action: 'already_liked' };
    }
    
    // Step 2: Optimistic update to Redis (immediate visibility)
    await Promise.all([
      this.redis.sadd(`post:${postId}:likers`, userId),
      this.redis.incr(`post:${postId}:like_count`)
    ]);
    
    // Step 3: Queue durable write (eventual persistence)
    await this.eventQueue.publish('LikeCreated', {
      likeId,
      userId,
      postId,
      timestamp: Date.now()
    });
    
    // Return immediately - don't wait for DB
    // Like count might be slightly off across replicas, but:
    // - User sees their own like immediately (read-your-writes via same Redis)
    // - Other users see eventually consistent count (acceptable)
    // - Durability is guaranteed via event queue
    
    return { 
      success: true, 
      action: 'liked',
      note: 'Count is eventually consistent across regions'
    };
  }
  
  async getLikeCount(postId: string): Promise<number> {
    // Fast read from Redis - might be slightly behind
    const count = await this.redis.get(`post:${postId}:like_count`);
    return parseInt(count || '0');
  }
}
 
// Background worker: Event → PostgreSQL (source of truth)
class LikeEventProcessor {
  async processLikeCreated(event: LikeCreatedEvent) {
    // Idempotent upsert to PostgreSQL
    await this.postgres.query(`
      INSERT INTO likes (like_id, user_id, post_id, created_at)
      VALUES ($1, $2, $3, $4)
      ON CONFLICT (like_id) DO NOTHING
    `, [event.likeId, event.userId, event.postId, event.timestamp]);
    
    // Update materialized count (for consistency with Redis)
    await this.postgres.query(`
      INSERT INTO post_stats (post_id, like_count)
      VALUES ($1, 1)
      ON CONFLICT (post_id) 
      DO UPDATE SET like_count = post_stats.like_count + 1
    `, [event.postId]);
  }
}

When BASE is Dangerous: Avoid These Scenarios

Just as important as knowing when BASE is acceptable is knowing when it's dangerous. These scenarios require ACID consistency—eventual consistency will cause real problems.

Never Use BASE For These

•Money Movement — Bank transfers, payments, refunds. Double-charging or double-crediting is unacceptable. Use ACID.
•Inventory for Checkout — Overselling causes customer anger, operational cost. Check inventory with ACID at purchase time.
•Booking/Reservations — Double-booking hotels, flights, appointments is unacceptable. Exclusive locks needed.
•User Authentication State — Account disabled/deleted must reflect immediately. Security risk otherwise.
•Resource Quotas — API rate limits, storage quotas. Allowing overages means revenue loss or abuse.
•Distributed Locks — Mutual exclusion requirements. Two processes holding 'exclusive' lock is a bug.
•Regulatory Compliance — Audit trails, financial records. Regulatory requirements often mandate strong consistency.
•Unique Constraints — Usernames, email addresses, order numbers. Duplicates cause real problems.

The Inventory Anti-Pattern

A common mistake: using eventually consistent reads for inventory during checkout. 'We have 5 in stock' → user purchases → actually 0 in stock (other purchases not yet replicated). Result: Overselling, cancelled orders, angry customers. Always check inventory with strong consistency at the moment of purchase.

BASE Danger Signs
Warning Sign	Why It's Dangerous	Solution
Value is money or credit	Incorrect balances = real loss	ACID for all money operations
Resource is exclusive	Multiple 'owners' = conflict	Distributed lock with ACID
Legal/compliance involved	Audit failures = penalties	ACID with audit trail
User safety affected	Wrong state = harm	ACID for safety-critical
Uniqueness required	Duplicates cause cascade failures	ACID with unique constraints
Conflicts are expensive	Compensation cost > availability benefit	ACID to prevent conflicts

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
// CORRECT: ACID for inventory at checkout
// BASE was used for browsing (catalog), but checkout needs ACID
 
class CheckoutService {
  private acidDatabase: PostgresDB;
  
  async checkout(
    cartItems: CartItem[], 
    userId: string
  ): Promise<CheckoutResult> {
    
    // ACID transaction - all or nothing
    return await this.acidDatabase.transaction(async (tx) => {
      const reservations: InventoryReservation[] = [];
      
      for (const item of cartItems) {
        // Lock row for update - prevents concurrent modifications
        const inventory = await tx.query(`
          SELECT quantity_available, quantity_reserved
          FROM inventory
          WHERE product_id = $1
          FOR UPDATE  -- Critical: exclusive lock
        `, [item.productId]);
        
        if (inventory.quantity_available < item.quantity) {
          // Abort entire transaction
          throw new InsufficientInventoryError(
            `Only ${inventory.quantity_available} of ${item.productId} available`
          );
        }
        
        // Reserve inventory atomically
        await tx.query(`
          UPDATE inventory
          SET 
            quantity_available = quantity_available - $1,
            quantity_reserved = quantity_reserved + $1
          WHERE product_id = $2
        `, [item.quantity, item.productId]);
        
        reservations.push({
          productId: item.productId,
          quantity: item.quantity
        });
      }
      
      // Create order with reserved items
      const order = await tx.query(`
        INSERT INTO orders (user_id, status, items, created_at)
        VALUES ($1, 'PENDING', $2, NOW())
        RETURNING id
      `, [userId, JSON.stringify(reservations)]);
      
      // All succeeded - commit transaction
      return {
        success: true,
        orderId: order.id,
        reservations
      };
    });
    
    // If anything fails, entire transaction rolls back
    // No partial reservations, no inconsistent state
    // This MUST be ACID - BASE would cause overselling
  }
}
 
// WRONG: This would cause overselling
class BrokenCheckoutService {
  private eventuallyConsistentDB: CassandraDB;
  
  async brokenCheckout(cartItems: CartItem[]) {
    for (const item of cartItems) {
      // BAD: Eventually consistent read - might be stale!
      const inventory = await this.eventuallyConsistentDB.read(
        `inventory:${item.productId}`
      );
      
      if (inventory.available >= item.quantity) {
        // BAD: No atomicity - race condition!
        await this.eventuallyConsistentDB.write(
          `inventory:${item.productId}`,
          { available: inventory.available - item.quantity }
        );
      }
    }
    // Result: Multiple users can "see" available inventory
    // and all try to reserve it = overselling
  }
}

Risk Assessment for Borderline Cases

Many use cases fall in a gray area—not obviously BASE-friendly, not obviously requiring ACID. For these borderline cases, use a structured risk assessment.

The BASE Risk Assessment Checklist:

For each operation, answer these questions. Score 1 point for each 'Yes'. Higher scores favor ACID; lower scores favor BASE.

Risk Assessment Questions
	Question	If Yes, Score
1	Does inconsistency cause financial loss?	+3
2	Does inconsistency cause legal/regulatory issues?	+3
3	Does inconsistency affect user safety?	+3
4	Does inconsistency cause permanent data corruption?	+2
5	Does inconsistency require expensive compensation?	+2
6	Is the operation non-idempotent?	+2
7	Do users expect immediate visibility to others?	+1
8	Is there high conflict potential (many writers)?	+1
9	Does inconsistency affect trust/reputation?	+1
10	Is compensation (rollback) complex?	+1

Interpreting Your Score:

Score	Recommendation	Rationale
0-3	BASE is likely fine	Low risk, high availability benefit
4-6	Consider hybrid	Use ACID for write, BASE for read
7-10	Hybrid with caution	ACID for core, carefully designed BASE edges
11+	ACID required	Risk too high for eventual consistency

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
// Example risk assessments for borderline cases
 
interface RiskAssessment {
  operation: string;
  scores: Record<string, number>;
  totalScore: number;
  recommendation: 'BASE' | 'HYBRID' | 'ACID';
  rationale: string;
}
 
const assessments: RiskAssessment[] = [
  {
    operation: "User profile bio update",
    scores: {
      financialLoss: 0,
      legalIssues: 0,
      userSafety: 0,
      dataCorruption: 0,
      expensiveCompensation: 0,
      nonIdempotent: 0,
      immediateVisibility: 1,  // Users like seeing changes immediately
      highConflict: 0,          // User owns their own profile
      trustImpact: 0,
      complexRollback: 0
    },
    totalScore: 1,
    recommendation: 'BASE',
    rationale: 'User-partitioned data, idempotent writes, low impact of delay'
  },
  
  {
    operation: "Comment on post",
    scores: {
      financialLoss: 0,
      legalIssues: 0,
      userSafety: 0,
      dataCorruption: 0,
      expensiveCompensation: 0,
      nonIdempotent: 1,  // Adding comment is not naturally idempotent
      immediateVisibility: 1,
      highConflict: 0,   // Comments are append-only
      trustImpact: 0,
      complexRollback: 0
    },
    totalScore: 2,
    recommendation: 'BASE',
    rationale: 'With idempotency key, can be made safe. Visibility delay acceptable.'
  },
  
  {
    operation: "Group membership change",
    scores: {
      financialLoss: 0,
      legalIssues: 1,   // Access control has compliance implications
      userSafety: 0,
      dataCorruption: 0,
      expensiveCompensation: 1,
      nonIdempotent: 0,
      immediateVisibility: 1,  // Security expects immediate effect
      highConflict: 1,         // Admins might conflict on membership
      trustImpact: 1,          // Security expectations
      complexRollback: 0
    },
    totalScore: 5,
    recommendation: 'HYBRID',
    rationale: 'Use ACID for membership write, cache for read. Invalidate on change.'
  },
  
  {
    operation: "Subscription upgrade/downgrade",
    scores: {
      financialLoss: 3,  // Wrong tier = wrong billing
      legalIssues: 2,    // Billing compliance
      userSafety: 0,
      dataCorruption: 0,
      expensiveCompensation: 2,  // Refund processing
      nonIdempotent: 2,  // Upgrade is a state change
      immediateVisibility: 1,
      highConflict: 0,
      trustImpact: 1,
      complexRollback: 1
    },
    totalScore: 12,
    recommendation: 'ACID',
    rationale: 'Financial impact too high. Subscription state must be strongly consistent.'
  }
];

Real-World Case Studies

Let's examine how major companies have made BASE decisions for specific features.

Case Study: Amazon Shopping Cart

•Challenge: Shopping cart must be available even during data center failures. Lost cart = lost sale.
•Decision: BASE consistency using DynamoDB. Cart data replicated across regions with eventual consistency.
•Trade-off accepted: User might add item, then see cart on different device without item momentarily.
•Mitigation: Read-your-writes consistency for same session. Merge conflicts by combining items (never lose).
•Result: 99.999% availability. Customers rarely notice brief inconsistency. Sales preserved during outages.
•ACID still used for: Payment processing, order creation, inventory reservation at checkout.

Case Study: Facebook News Feed

•Challenge: Billions of users, each with personalized feed. Real-time updates expected.
•Decision: BASE consistency. Feeds are eventually consistent across regions.
•Trade-off accepted: Post from friend might appear 1-2 seconds later on your feed.
•Mitigation: Fan-out on write. Posts pushed to followers' feed caches. Priority for close friends.
•Result: Low-latency feed delivery worldwide. Users perceive 'real-time' despite eventual consistency.
•ACID still used for: Account actions (disable, delete), privacy settings, ad billing.

Case Study: Netflix Viewing History

•Challenge: Track viewing history across all devices for 200M+ users. Resume watching anywhere.
•Decision: BASE consistency using Cassandra. History replicated eventually across regions.
•Trade-off accepted: Start watching on TV, immediate switch to phone might show slightly old position.
•Mitigation: Read-your-writes within same session. UI shows 'syncing' indicator when appropriate.
•Result: Massive scale achieved. Resume position 'close enough' for user satisfaction.
•ACID still used for: Subscription state, billing, account authentication.

Case Study: Slack Messages

•Challenge: Real-time messaging for millions of teams. Message ordering critical.
•Decision: Hybrid approach. Messages have ACID-guaranteed ordering within channel.
•Trade-off: Users in different regions might see messages appear at slightly different times.
•Mitigation: Local timestamps + server-assigned sequence numbers. Eventually consistent view convergence.
•Result: Perceived real-time messaging. Strict ordering within channel. Slight cross-region delay.
•ACID still used for: Channel membership, workspace settings, billing.

Pattern: BASE for User Experience, ACID for Business Logic

Notice the pattern: These companies use BASE for user-facing features where availability and low latency matter most (carts, feeds, history, messages). They use ACID for business-critical operations where correctness is paramount (payments, subscriptions, account state). This hybrid approach gives the best of both worlds.

Implementation Guidelines for BASE

When you've decided BASE is appropriate, follow these guidelines to implement it correctly.

BASE Implementation Checklist

•Design for idempotency from the start — Every write operation should be safely repeatable. Use idempotency keys for all mutations.
•Implement read-your-writes — Users should always see their own changes immediately. Route reads to same node as writes or include write timestamp.
•Choose a conflict resolution strategy — LWW, merge, CRDT. Document and test the strategy. Ensure it matches business semantics.
•Add version/timestamp to all data — Track data freshness. Allow clients to request minimum freshness if needed.
•Implement monitoring for convergence — Measure actual replication lag. Alert on excessive lag. Track conflict rates.
•Design graceful degradation — What happens when consistency is worse than expected? Fallback to cached data? Show warning?
•Test eventual consistency explicitly — Simulate replication lag, partitions, conflicts in tests. Don't assume happy path.
•Document consistency expectations — APIs should indicate consistency level. Clients should understand what they're getting.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
// Template for implementing BASE-style operations
 
interface BASEOperation<T> {
  // Unique key for idempotency
  idempotencyKey: string;
  
  // Timestamp for ordering/conflict resolution
  timestamp: number;
  
  // The actual data
  payload: T;
  
  // Consistency hints for clients
  consistency: {
    level: 'eventual' | 'read-your-writes' | 'monotonic';
    maxStalenessMs?: number;
  };
}
 
class BASEServiceTemplate<T> {
  private primaryStore: DistributedStore;
  private idempotencyCache: IdempotencyCache;
  
  async write(operation: BASEOperation<T>): Promise<WriteResult> {
    // 1. Idempotency check
    const existing = await this.idempotencyCache.get(operation.idempotencyKey);
    if (existing) {
      console.log('Idempotent retry detected, returning cached result');
      return existing.result;
    }
    
    // 2. Perform write with version
    const result = await this.primaryStore.write({
      key: this.deriveKey(operation),
      value: operation.payload,
      timestamp: operation.timestamp,
      metadata: {
        idempotencyKey: operation.idempotencyKey,
        writtenAt: Date.now()
      }
    });
    
    // 3. Cache result for idempotency (with TTL)
    await this.idempotencyCache.set(
      operation.idempotencyKey,
      { result, expiry: Date.now() + 24 * 60 * 60 * 1000 }
    );
    
    // 4. Return with consistency metadata
    return {
      success: true,
      version: result.version,
      consistency: operation.consistency,
      propagationEstimate: this.estimatePropagationTime()
    };
  }
  
  async read(
    key: string, 
    options: ReadOptions = {}
  ): Promise<ReadResult<T>> {
    // 5. Read with freshness check
    const result = await this.primaryStore.read(key);
    
    if (!result) {
      return { found: false, consistency: { level: 'eventual' } };
    }
    
    // 6. Check freshness for read-your-writes
    if (options.minVersion && result.version < options.minVersion) {
      // Data is stale relative to a write we know about
      if (options.waitForFreshness) {
        // Wait for propagation
        return await this.waitForVersion(key, options.minVersion, options.timeoutMs);
      } else {
        // Return with staleness warning
        return {
          found: true,
          value: result.value,
          version: result.version,
          stale: true,
          consistency: { level: 'eventual', staleness: Date.now() - result.timestamp }
        };
      }
    }
    
    return {
      found: true,
      value: result.value,
      version: result.version,
      stale: false,
      consistency: { level: options.minVersion ? 'read-your-writes' : 'eventual' }
    };
  }
  
  private estimatePropagationTime(): number {
    // Based on monitoring data
    return this.monitoringService.getP99PropagationTimeMs();
  }
}

Summary: Choosing BASE with Confidence

We've explored when BASE consistency is acceptable and how to implement it safely. Let's consolidate the key takeaways:

Key Takeaways

•Certain domain characteristics favor BASE — Monotonic operations, idempotent actions, append-only data, and statistical workloads are natural fits.
•Social, analytics, and content features typically work with BASE — Like counts, feeds, recommendations, and media delivery benefit from availability over consistency.
•Financial and safety-critical operations require ACID — Money, inventory at checkout, reservations, and security state need strong consistency.
•Use risk assessment for borderline cases — Score operations against criteria like financial impact, legal requirements, and conflict potential.
•Major companies use hybrid approaches — BASE for user experience, ACID for business logic. This pattern works at massive scale.
•Implement BASE correctly with patterns — Idempotency, read-your-writes, conflict resolution, versioning, and monitoring are essential.

Module Complete:

Congratulations! You've completed the BASE Properties module. You now understand:

Basically Available: Systems prioritize response over perfection
Soft State: Data changes over time without explicit modification
Eventually Consistent: All replicas converge to the same value
ACID vs BASE: Trade-offs and when to use each
When BASE is Acceptable: Concrete scenarios and decision frameworks

This knowledge is foundational for designing distributed systems that scale. In the next module, we'll explore Data Modeling Fundamentals—how to structure your data for both ACID and BASE systems.

Module Complete

You now have the knowledge and frameworks to confidently choose BASE consistency when appropriate—and recognize when it's not. This is a crucial skill for any engineer designing systems at scale. BASE isn't a compromise; it's a deliberate choice that enables availability, performance, and scalability for the right use cases.