Skip to content
advanced Phase 85 · Distributed Fundamentals

Eventual Consistency

Eventual consistency models, conflict resolution, and data synchronization strategies

45m
0 problems
Topic Progress 0%

Consistency Models

Consistency Spectrum

Strong Consistency <─────────────> Eventual Consistency

Linearizability → Sequential → Causal → Eventual

Consistency <───────────────────> Performance

Model Comparison

Model               | Guarantee                    | Performance
────────────────────|──────────────────────────────|─────────────
Strong              | Read returns latest write    | Slow
Eventual            | Read eventually consistent   | Fast
Causal              | Causally related ops ordered  | Medium
Read-your-writes    | See your own writes          | Medium

Magento Consistency Points

Strong Consistency Needed:
- Payment processing
- Inventory deduction
- Order finalization

Eventual Consistency Acceptable:
- Search index updates
- Product catalog cache
- Analytics data
- Recommendation engine

Conflict Resolution

Conflict Scenarios

1. Concurrent updates to same entity
2. Replication lag causing stale reads
3. Cache-DB inconsistency
4. Multi-region data conflicts

Resolution Strategies

Strategy           | Approach                   | Use Case
───────────────────|────────────────────────────|─────────────
Last-write-wins     | Latest timestamp wins      | Simple conflicts
Merge               | Combine changes            | Additive data
Manual resolution   | Human decides              | Critical data
Custom rules        | Business logic             | Domain-specific

Last-Write-Wins

function resolveConflict($local, $remote) {
    $localTime = strtotime($local['updated_at']);
    $remoteTime = strtotime($remote['updated_at']);
    if ($remoteTime > $localTime) {
        return $remote;
    }
    return $local;
}

Vector Clocks

// Track causality
$vectorClock = ['node1' => 5, 'node2' => 3, 'node3' => 7];

function compare($a, $b) {
    $aAfterB = false;
    $bAfterA = false;
    foreach (array_keys($a + $b) as $key) {
        if (($a[$key] ?? 0) > ($b[$key] ?? 0)) $aAfterB = true;
        if (($b[$key] ?? 0) > ($a[$key] ?? 0)) $bAfterA = true;
    }
    if ($aAfterB && !$bAfterA) return 1;  // A happened after B
    if ($bAfterA && !$aAfterB) return -1; // B happened after A
    return 0; // Concurrent
}

Data Synchronization

Sync Patterns

Pattern            | Description              | Use Case
───────────────────|──────────────────────────|──────────────
Synchronous        | Wait for all replicas    | Strong consistency
Asynchronous       | Fire and forget          | Eventual consistency
Batch              | Periodic sync             | Analytics
CDC                | Change data capture       | Real-time sync

Change Data Capture

MySQL → Debezium → Kafka → Consumers

1. Debezium reads MySQL binlog
2. Captures row-level changes
3. Publishes to Kafka topics
4. Consumers update downstream systems

Magento Sync Example

// Async sync to search index
$eventManager->dispatch('catalog_product_save_after', [
    'product' => $product
]);

// Observer publishes sync event
public function execute(EventObserver $observer) {
    $product = $observer->getEvent()->getProduct();
    $this->publisher->publish('catalog.sync', [
        'entity_id' => $product->getId(),
        'action' => 'update',
        'data' => $product->toArray()
    ]);
}
// Search index eventually reflects changes

Handling Eventual Consistency

Strategies for Magento

1. Read-your-writes for user sessions
2. Cache invalidation on write
3. Background sync for non-critical data
4. Version vectors for conflict detection
5. Retry with backoff for sync failures

Read-Your-Writes

// Ensure user sees their own changes
function getProduct($userId) {
    // Check if user recently updated
    $lastWrite = $this->cache->get('user_write_' . $userId);
    if ($lastWrite) {
        // Read from primary (strong consistency)
        return $this->primaryDb->fetch($productId);
    }
    // Read from replica (eventual consistency)
    return $this->replicaDb->fetch($productId);
}

Consistency Checks

#!/bin/bash
# Periodic consistency check
SOURCE_COUNT=$(mysql -e "SELECT COUNT(*) FROM products" -N)
SEARCH_COUNT=$(curl -s "http://opensearch:9200/products/_count" | jq .count)

if [ $SOURCE_COUNT -ne $SEARCH_COUNT ]; then
    echo "ALERT: Data inconsistency detected"
    echo "DB: $SOURCE_COUNT, Search: $SEARCH_COUNT"
fi

Quiz

1. What is eventual consistency?

Question 1 options

2. When is strong consistency required?

Question 2 options

3. What is Change Data Capture (CDC)?

Question 3 options

Flashcards

Question

Eventual consistency?

Answer

System converges to consistent state over time, not immediately

Question

Last-write-wins?

Answer

Conflict resolution: latest timestamp wins

Question

CDC purpose?

Answer

Capture database changes from binlog for real-time sync

Question

Strong consistency when?

Answer

Payment processing, inventory deduction, order finalization

Revision Notes

Key Takeaways

  • 1. Consistency spectrum from strong to eventual with trade-offs
  • 2. Strong consistency for payments, eventual for search/cache
  • 3. Conflict resolution: last-write-wins, merge, or manual
  • 4. CDC captures database changes for downstream sync
  • 5. Read-your-writes ensures users see their own changes

Interview Tips

  • Explain consistency models and their trade-offs
  • Discuss conflict resolution strategies
  • Describe when strong vs eventual consistency is appropriate

Cheat Sheet

Consistency:
  Strong: Read returns latest write (slow)
  Eventual: Converges over time (fast)
  Causal: Causally related ops ordered

Conflict Resolution:
  Last-write-wins: Latest timestamp
  Merge: Combine changes
  Manual: Human decides

Sync Patterns:
  Synchronous: Strong consistency
  Asynchronous: Eventual consistency
  CDC: Change data capture from binlog