Chapter 4: Consistency Models in DynamoDB

Introduction

Consistency in distributed systems is one of the most critical concepts to understand when working with DynamoDB, and it is one of the topics most frequently tested in system design interviews. As a distributed database that replicates data across three Availability Zones within a region, DynamoDB must balance consistency, availability, and partition tolerance according to the CAP theorem. What makes DynamoDB’s consistency model practically interesting is that it gives you a per-request choice: you can read with eventual consistency (faster, cheaper, potentially stale) or strong consistency (slower, more expensive, always fresh). This per-request flexibility means you don’t have to commit to a single consistency level for your entire application — you can use strong consistency for critical reads (like checking account balances before a transfer) and eventual consistency for tolerant reads (like displaying a product catalog). This chapter explores DynamoDB’s consistency models, their implications, and how to choose the right consistency level for your application.

Understanding Distributed Consistency

The CAP Theorem

The CAP theorem states that a distributed system can provide at most two of the following three guarantees:

Consistency: All nodes see the same data at the same time
Availability: Every request receives a response (success or failure)
Partition Tolerance: The system continues to operate despite network partitions

<svg viewBox="0 0 800 600" xmlns="http://www.w3.org/2000/svg">
  <!-- Title -->
  <text x="400" y="30" font-size="18" font-weight="bold" text-anchor="middle" fill="#333">
    CAP Theorem: Choose Two
  </text>

  <!-- Triangle -->
  <polygon points="400,100 650,500 150,500" fill="none" stroke="#333" stroke-width="3"/>

  <!-- C vertex -->
  <circle cx="400" cy="100" r="60" fill="#1976d2" stroke="#0d47a1" stroke-width="2"/>
  <text x="400" y="95" font-size="16" font-weight="bold" text-anchor="middle" fill="#fff">
    Consistency
  </text>
  <text x="400" y="115" font-size="12" text-anchor="middle" fill="#fff">
    (C)
  </text>

  <!-- A vertex -->
  <circle cx="150" cy="500" r="60" fill="#4caf50" stroke="#2e7d32" stroke-width="2"/>
  <text x="150" y="495" font-size="16" font-weight="bold" text-anchor="middle" fill="#fff">
    Availability
  </text>
  <text x="150" y="515" font-size="12" text-anchor="middle" fill="#fff">
    (A)
  </text>

  <!-- P vertex -->
  <circle cx="650" cy="500" r="60" fill="#ff9800" stroke="#f57c00" stroke-width="2"/>
  <text x="650" y="490" font-size="14" font-weight="bold" text-anchor="middle" fill="#fff">
    Partition
  </text>
  <text x="650" y="505" font-size="14" font-weight="bold" text-anchor="middle" fill="#fff">
    Tolerance
  </text>
  <text x="650" y="520" font-size="12" text-anchor="middle" fill="#fff">
    (P)
  </text>

  <!-- CA edge -->
  <rect x="230" y="280" width="140" height="60" fill="#e3f2fd" stroke="#1976d2" stroke-width="2" rx="5"/>
  <text x="300" y="305" font-size="13" font-weight="bold" text-anchor="middle" fill="#1976d2">
    CA System
  </text>
  <text x="300" y="325" font-size="11" text-anchor="middle" fill="#333">
    Traditional
  </text>
  <text x="300" y="340" font-size="11" text-anchor="middle" fill="#333">
    RDBMS
  </text>

  <!-- CP edge -->
  <rect x="450" y="280" width="140" height="60" fill="#fff3e0" stroke="#ff9800" stroke-width="2" rx="5"/>
  <text x="520" y="305" font-size="13" font-weight="bold" text-anchor="middle" fill="#f57c00">
    CP System
  </text>
  <text x="520" y="325" font-size="11" text-anchor="middle" fill="#333">
    MongoDB
  </text>
  <text x="520" y="340" font-size="11" text-anchor="middle" fill="#333">
    HBase
  </text>

  <!-- AP edge -->
  <rect x="340" y="470" width="140" height="60" fill="#e8f5e9" stroke="#4caf50" stroke-width="2" rx="5"/>
  <text x="410" y="495" font-size="13" font-weight="bold" text-anchor="middle" fill="#4caf50">
    AP System
  </text>
  <text x="410" y="515" font-size="11" text-anchor="middle" fill="#333">
    DynamoDB
  </text>
  <text x="410" y="530" font-size="11" text-anchor="middle" fill="#333">
    Cassandra
  </text>

  <!-- Note -->
  <rect x="200" y="560" width="400" height="30" fill="#fff9c4" stroke="#fbc02d" stroke-width="1" rx="3"/>
  <text x="400" y="580" font-size="11" text-anchor="middle" fill="#333">
    In practice, partition tolerance is mandatory for distributed systems
  </text>
</svg>

DynamoDB chooses Availability and Partition Tolerance (AP), offering eventual consistency by default with an option for strong consistency on reads. It is worth noting that the CAP theorem, while a useful mental framework, is somewhat of a simplification. Daniel Abadi’s PACELC theorem provides a more nuanced view: even when there is no partition (the normal case), a system must choose between latency (L) and consistency (C). DynamoDB’s two consistency options map directly to this: eventually consistent reads optimize for latency, while strongly consistent reads optimize for consistency, even when the network is functioning perfectly.

Replication in DynamoDB

DynamoDB automatically replicates data across three Availability Zones within a region:

<svg viewBox="0 0 900 600" xmlns="http://www.w3.org/2000/svg">
  <!-- Title -->
  <text x="450" y="30" font-size="18" font-weight="bold" text-anchor="middle" fill="#333">
    DynamoDB Cross-AZ Replication
  </text>

  <!-- Region Box -->
  <rect x="50" y="60" width="800" height="520" fill="#f5f5f5" stroke="#666" stroke-width="2" stroke-dasharray="5,5" rx="5"/>
  <text x="450" y="90" font-size="16" font-weight="bold" text-anchor="middle" fill="#666">
    AWS Region (e.g., us-east-1)
  </text>

  <!-- AZ 1 -->
  <rect x="80" y="120" width="220" height="420" fill="#e3f2fd" stroke="#1976d2" stroke-width="2" rx="5"/>
  <text x="190" y="150" font-size="14" font-weight="bold" text-anchor="middle" fill="#1976d2">
    Availability Zone 1
  </text>

  <!-- Storage Node 1 -->
  <rect x="120" y="180" width="140" height="100" fill="#fff" stroke="#1976d2" stroke-width="2" rx="3"/>
  <text x="190" y="205" font-size="13" font-weight="bold" text-anchor="middle" fill="#333">
    Storage Node
  </text>
  <rect x="130" y="220" width="120" height="25" fill="#bbdefb" stroke="#1976d2" stroke-width="1" rx="2"/>
  <text x="190" y="237" font-size="11" text-anchor="middle" fill="#333">
    Partition: A-M
  </text>
  <rect x="130" y="250" width="120" height="20" fill="#e3f2fd" stroke="#1976d2" stroke-width="1" rx="2"/>
  <text x="190" y="264" font-size="10" text-anchor="middle" fill="#333">
    Replica: Leader
  </text>

  <!-- Storage Node 2 -->
  <rect x="120" y="310" width="140" height="100" fill="#fff" stroke="#1976d2" stroke-width="2" rx="3"/>
  <text x="190" y="335" font-size="13" font-weight="bold" text-anchor="middle" fill="#333">
    Storage Node
  </text>
  <rect x="130" y="350" width="120" height="25" fill="#bbdefb" stroke="#1976d2" stroke-width="1" rx="2"/>
  <text x="190" y="367" font-size="11" text-anchor="middle" fill="#333">
    Partition: N-Z
  </text>
  <rect x="130" y="380" width="120" height="20" fill="#e3f2fd" stroke="#1976d2" stroke-width="1" rx="2"/>
  <text x="190" y="394" font-size="10" text-anchor="middle" fill="#333">
    Replica: Follower
  </text>

  <!-- AZ 2 -->
  <rect x="340" y="120" width="220" height="420" fill="#e8f5e9" stroke="#4caf50" stroke-width="2" rx="5"/>
  <text x="450" y="150" font-size="14" font-weight="bold" text-anchor="middle" fill="#4caf50">
    Availability Zone 2
  </text>

  <!-- Storage Node 3 -->
  <rect x="380" y="180" width="140" height="100" fill="#fff" stroke="#4caf50" stroke-width="2" rx="3"/>
  <text x="450" y="205" font-size="13" font-weight="bold" text-anchor="middle" fill="#333">
    Storage Node
  </text>
  <rect x="390" y="220" width="120" height="25" fill="#c8e6c9" stroke="#4caf50" stroke-width="1" rx="2"/>
  <text x="450" y="237" font-size="11" text-anchor="middle" fill="#333">
    Partition: A-M
  </text>
  <rect x="390" y="250" width="120" height="20" fill="#e8f5e9" stroke="#4caf50" stroke-width="1" rx="2"/>
  <text x="450" y="264" font-size="10" text-anchor="middle" fill="#333">
    Replica: Follower
  </text>

  <!-- Storage Node 4 -->
  <rect x="380" y="310" width="140" height="100" fill="#fff" stroke="#4caf50" stroke-width="2" rx="3"/>
  <text x="450" y="335" font-size="13" font-weight="bold" text-anchor="middle" fill="#333">
    Storage Node
  </text>
  <rect x="390" y="350" width="120" height="25" fill="#c8e6c9" stroke="#4caf50" stroke-width="1" rx="2"/>
  <text x="450" y="367" font-size="11" text-anchor="middle" fill="#333">
    Partition: N-Z
  </text>
  <rect x="390" y="380" width="120" height="20" fill="#e8f5e9" stroke="#4caf50" stroke-width="1" rx="2"/>
  <text x="450" y="394" font-size="10" text-anchor="middle" fill="#333">
    Replica: Leader
  </text>

  <!-- AZ 3 -->
  <rect x="600" y="120" width="220" height="420" fill="#fff3e0" stroke="#ff9800" stroke-width="2" rx="5"/>
  <text x="710" y="150" font-size="14" font-weight="bold" text-anchor="middle" fill="#ff9800">
    Availability Zone 3
  </text>

  <!-- Storage Node 5 -->
  <rect x="640" y="180" width="140" height="100" fill="#fff" stroke="#ff9800" stroke-width="2" rx="3"/>
  <text x="710" y="205" font-size="13" font-weight="bold" text-anchor="middle" fill="#333">
    Storage Node
  </text>
  <rect x="650" y="220" width="120" height="25" fill="#ffe0b2" stroke="#ff9800" stroke-width="1" rx="2"/>
  <text x="710" y="237" font-size="11" text-anchor="middle" fill="#333">
    Partition: A-M
  </text>
  <rect x="650" y="250" width="120" height="20" fill="#fff3e0" stroke="#ff9800" stroke-width="1" rx="2"/>
  <text x="710" y="264" font-size="10" text-anchor="middle" fill="#333">
    Replica: Follower
  </text>

  <!-- Storage Node 6 -->
  <rect x="640" y="310" width="140" height="100" fill="#fff" stroke="#ff9800" stroke-width="2" rx="3"/>
  <text x="710" y="335" font-size="13" font-weight="bold" text-anchor="middle" fill="#333">
    Storage Node
  </text>
  <rect x="650" y="350" width="120" height="25" fill="#ffe0b2" stroke="#ff9800" stroke-width="1" rx="2"/>
  <text x="710" y="367" font-size="11" text-anchor="middle" fill="#333">
    Partition: N-Z
  </text>
  <rect x="650" y="380" width="120" height="20" fill="#fff3e0" stroke="#ff9800" stroke-width="1" rx="2"/>
  <text x="710" y="394" font-size="10" text-anchor="middle" fill="#333">
    Replica: Follower
  </text>

  <!-- Replication Arrows -->
  <path d="M 260 230 L 380 230" stroke="#1976d2" stroke-width="2" fill="none" marker-end="url(#arrowblue)" stroke-dasharray="5,5"/>
  <path d="M 520 230 L 640 230" stroke="#4caf50" stroke-width="2" fill="none" marker-end="url(#arrowgreen)" stroke-dasharray="5,5"/>

  <path d="M 260 360 L 380 360" stroke="#1976d2" stroke-width="2" fill="none" marker-end="url(#arrowblue)" stroke-dasharray="5,5"/>
  <path d="M 520 360 L 640 360" stroke="#4caf50" stroke-width="2" fill="none" marker-end="url(#arrowgreen)" stroke-dasharray="5,5"/>

  <!-- Info Box -->
  <rect x="150" y="460" width="600" height="60" fill="#fff" stroke="#666" stroke-width="2" rx="5"/>
  <text x="450" y="485" font-size="13" font-weight="bold" text-anchor="middle" fill="#333">
    Automatic 3-Way Replication
  </text>
  <text x="450" y="505" font-size="11" text-anchor="middle" fill="#666">
    Each partition is replicated to 3 storage nodes across 3 AZs
  </text>

  <!-- Arrow markers -->
  <defs>
    <marker id="arrowblue" markerWidth="10" markerHeight="10" refX="9" refY="3" orient="auto">
      <polygon points="0 0, 10 3, 0 6" fill="#1976d2"/>
    </marker>
    <marker id="arrowgreen" markerWidth="10" markerHeight="10" refX="9" refY="3" orient="auto">
      <polygon points="0 0, 10 3, 0 6" fill="#4caf50"/>
    </marker>
  </defs>
</svg>

DynamoDB Consistency Models

Eventual Consistency (Default)

With eventually consistent reads, responses might not reflect recently completed writes. However, consistency is typically achieved within one second. Characteristics:

Best performance: Lower latency and higher throughput
Cost-efficient: Consumes half the RCUs of strongly consistent reads
Eventually consistent: Reads may return stale data temporarily
Default option: Used unless you specify otherwise

// Eventually consistent read (default)
const params = {
  TableName: 'Users',
  Key: {
    userId: '12345'
  }
  // ConsistentRead: false is the default
};

const result = await dynamodb.get(params).promise();

Timeline Example:

Time: T0    T1    T2    T3    T4
      |     |     |     |     |
AZ1:  [Write v2] ------------> v2
      |     |     |     |     |
AZ2:  v1 -----> v2 ----------> v2
      |     |     |     |     |
AZ3:  v1 ----------> v2 -----> v2
      |     |     |     |     |
Read: [v1 or v2] [v1 or v2] [v2]

- Write acknowledged at T0 (written to AZ1)
- Read at T1 might return v1 (from AZ2 or AZ3)
- Read at T3 will likely return v2 (all replicas updated)

Strong Consistency

Strongly consistent reads return a result that reflects all successful writes prior to the read. Characteristics:

Strong guarantees: Always returns the most recent data
Higher cost: Consumes twice the RCUs of eventual consistency
Slightly higher latency: Must coordinate across replicas
Opt-in: Must explicitly request

// Strongly consistent read
const params = {
  TableName: 'Users',
  Key: {
    userId: '12345'
  },
  ConsistentRead: true  // Request strong consistency
};

const result = await dynamodb.get(params).promise();

Timeline Example:

Time: T0    T1    T2    T3
      |     |     |     |
AZ1:  [Write v2] ------> v2
      |     |     |     |
AZ2:  v1 -----> v2 ----> v2
      |     |     |     |
AZ3:  v1 -----> v2 ----> v2
      |     |     |     |
Read:       [Wait...] [v2]

- Write initiated at T0
- Strong read waits for quorum before returning
- Read at T2 returns v2 (guaranteed latest)

Read-After-Write Consistency

DynamoDB provides read-after-write consistency for specific scenarios: Guaranteed Read-After-Write Consistency:

GetItem with same key immediately after PutItem/UpdateItem
Query/Scan of newly written items (within same session)
Transactional reads (TransactGetItems)

// Write-then-read scenario
await dynamodb.put({
  TableName: 'Users',
  Item: {
    userId: '12345',
    name: 'John Doe'
  }
}).promise();

// This read will see the write (read-after-write consistency)
const result = await dynamodb.get({
  TableName: 'Users',
  Key: { userId: '12345' }
}).promise();

// Returns: { userId: '12345', name: 'John Doe' }

Consistency Across Operations

GetItem and Query Operations

// GetItem - supports both consistency models
const eventualResult = await dynamodb.get({
  TableName: 'Users',
  Key: { userId: '12345' },
  ConsistentRead: false  // Default: eventual consistency
}).promise();

const strongResult = await dynamodb.get({
  TableName: 'Users',
  Key: { userId: '12345' },
  ConsistentRead: true   // Strong consistency
}).promise();

// Query - supports both consistency models
const queryResult = await dynamodb.query({
  TableName: 'Orders',
  KeyConditionExpression: 'userId = :uid',
  ExpressionAttributeValues: {
    ':uid': '12345'
  },
  ConsistentRead: true  // Optional: strong consistency
}).promise();

Scan Operations

// Scan - supports both consistency models
const scanResult = await dynamodb.scan({
  TableName: 'Products',
  FilterExpression: 'price < :maxPrice',
  ExpressionAttributeValues: {
    ':maxPrice': 100
  },
  ConsistentRead: true  // Optional: strong consistency
}).promise();

// Note: Strongly consistent scans are expensive!
// Only use when absolutely necessary

BatchGetItem

// BatchGetItem - eventual consistency only
const batchResult = await dynamodb.batchGet({
  RequestItems: {
    'Users': {
      Keys: [
        { userId: '12345' },
        { userId: '67890' }
      ]
      // ConsistentRead not supported for BatchGetItem!
    }
  }
}).promise();

// Workaround: Use parallel GetItem calls for strong consistency
const strongBatchResults = await Promise.all([
  dynamodb.get({
    TableName: 'Users',
    Key: { userId: '12345' },
    ConsistentRead: true
  }).promise(),
  dynamodb.get({
    TableName: 'Users',
    Key: { userId: '67890' },
    ConsistentRead: true
  }).promise()
]);

Global Secondary Indexes

Important: GSIs only support eventual consistency.

// Query GSI - eventual consistency only
const gsiResult = await dynamodb.query({
  TableName: 'Users',
  IndexName: 'EmailIndex',
  KeyConditionExpression: 'email = :email',
  ExpressionAttributeValues: {
    ':email': 'john@example.com'
  }
  // ConsistentRead: true NOT SUPPORTED for GSI!
}).promise();

// GSI propagation timeline:
// T0: Write to base table
// T1: Write acknowledged
// T2: GSI updated (typically milliseconds)
// T3: GSI read reflects write

// Possible scenarios:
// - Read at T1.5: Old value (GSI not yet updated)
// - Read at T3: New value (GSI updated)

Transactions

DynamoDB transactions provide ACID guarantees with serializable isolation.

// TransactWriteItems - immediately consistent
await dynamodb.transactWrite({
  TransactItems: [
    {
      Put: {
        TableName: 'Accounts',
        Item: { accountId: 'A123', balance: 1000 }
      }
    },
    {
      Update: {
        TableName: 'Accounts',
        Key: { accountId: 'B456' },
        UpdateExpression: 'SET balance = balance - :amount',
        ExpressionAttributeValues: { ':amount': 100 }
      }
    }
  ]
}).promise();

// TransactGetItems - serializable snapshot
const transactResult = await dynamodb.transactGet({
  TransactItems: [
    {
      Get: {
        TableName: 'Accounts',
        Key: { accountId: 'A123' }
      }
    },
    {
      Get: {
        TableName: 'Accounts',
        Key: { accountId: 'B456' }
      }
    }
  ]
}).promise();

// Returns consistent snapshot across all items

Consistency Trade-offs

<svg viewBox="0 0 800 600" xmlns="http://www.w3.org/2000/svg">
  <!-- Title -->
  <text x="400" y="30" font-size="18" font-weight="bold" text-anchor="middle" fill="#333">
    Consistency Model Trade-offs
  </text>

  <!-- Table Header -->
  <rect x="50" y="60" width="700" height="50" fill="#1976d2" stroke="#0d47a1" stroke-width="2"/>
  <text x="150" y="90" font-size="14" font-weight="bold" text-anchor="middle" fill="#fff">Aspect</text>
  <text x="350" y="90" font-size="14" font-weight="bold" text-anchor="middle" fill="#fff">Eventual Consistency</text>
  <text x="600" y="90" font-size="14" font-weight="bold" text-anchor="middle" fill="#fff">Strong Consistency</text>

  <!-- Row 1: Latency -->
  <rect x="50" y="110" width="700" height="60" fill="#e3f2fd" stroke="#90caf9" stroke-width="1"/>
  <text x="150" y="145" font-size="13" font-weight="bold" text-anchor="middle" fill="#333">Latency</text>
  <text x="350" y="135" font-size="12" text-anchor="middle" fill="#333">Lower</text>
  <text x="350" y="155" font-size="11" text-anchor="middle" fill="#666">(~5-10ms)</text>
  <text x="600" y="135" font-size="12" text-anchor="middle" fill="#333">Higher</text>
  <text x="600" y="155" font-size="11" text-anchor="middle" fill="#666">(~10-20ms)</text>

  <!-- Row 2: Cost -->
  <rect x="50" y="170" width="700" height="60" fill="#fff" stroke="#90caf9" stroke-width="1"/>
  <text x="150" y="205" font-size="13" font-weight="bold" text-anchor="middle" fill="#333">Cost (RCUs)</text>
  <text x="350" y="195" font-size="12" text-anchor="middle" fill="#333">0.5 RCU per 4KB</text>
  <text x="350" y="215" font-size="11" text-anchor="middle" fill="#4caf50">50% cheaper</text>
  <text x="600" y="195" font-size="12" text-anchor="middle" fill="#333">1 RCU per 4KB</text>
  <text x="600" y="215" font-size="11" text-anchor="middle" fill="#ff9800">More expensive</text>

  <!-- Row 3: Throughput -->
  <rect x="50" y="230" width="700" height="60" fill="#e3f2fd" stroke="#90caf9" stroke-width="1"/>
  <text x="150" y="265" font-size="13" font-weight="bold" text-anchor="middle" fill="#333">Throughput</text>
  <text x="350" y="265" font-size="12" text-anchor="middle" fill="#333">Higher</text>
  <text x="600" y="265" font-size="12" text-anchor="middle" fill="#333">Lower</text>

  <!-- Row 4: Freshness -->
  <rect x="50" y="290" width="700" height="60" fill="#fff" stroke="#90caf9" stroke-width="1"/>
  <text x="150" y="325" font-size="13" font-weight="bold" text-anchor="middle" fill="#333">Data Freshness</text>
  <text x="350" y="315" font-size="12" text-anchor="middle" fill="#333">May be stale</text>
  <text x="350" y="335" font-size="11" text-anchor="middle" fill="#666">(< 1 second)</text>
  <text x="600" y="315" font-size="12" text-anchor="middle" fill="#333">Always fresh</text>
  <text x="600" y="335" font-size="11" text-anchor="middle" fill="#666">(Latest value)</text>

  <!-- Row 5: Availability -->
  <rect x="50" y="350" width="700" height="60" fill="#e3f2fd" stroke="#90caf9" stroke-width="1"/>
  <text x="150" y="385" font-size="13" font-weight="bold" text-anchor="middle" fill="#333">Availability</text>
  <text x="350" y="385" font-size="12" text-anchor="middle" fill="#333">Higher (AP)</text>
  <text x="600" y="385" font-size="12" text-anchor="middle" fill="#333">Lower (CP)</text>

  <!-- Row 6: GSI Support -->
  <rect x="50" y="410" width="700" height="60" fill="#fff" stroke="#90caf9" stroke-width="1"/>
  <text x="150" y="445" font-size="13" font-weight="bold" text-anchor="middle" fill="#333">GSI Support</text>
  <text x="350" y="445" font-size="12" text-anchor="middle" fill="#4caf50">✓ Yes</text>
  <text x="600" y="445" font-size="12" text-anchor="middle" fill="#f44336">✗ No</text>

  <!-- Row 7: Use Cases -->
  <rect x="50" y="470" width="700" height="80" fill="#e3f2fd" stroke="#90caf9" stroke-width="1"/>
  <text x="150" y="515" font-size="13" font-weight="bold" text-anchor="middle" fill="#333">Best For</text>
  <text x="350" y="500" font-size="11" text-anchor="middle" fill="#333">• Analytics</text>
  <text x="350" y="518" font-size="11" text-anchor="middle" fill="#333">• Caching</text>
  <text x="350" y="536" font-size="11" text-anchor="middle" fill="#333">• High-throughput reads</text>
  <text x="600" y="500" font-size="11" text-anchor="middle" fill="#333">• Financial transactions</text>
  <text x="600" y="518" font-size="11" text-anchor="middle" fill="#333">• Inventory management</text>
  <text x="600" y="536" font-size="11" text-anchor="middle" fill="#333">• Critical data accuracy</text>
</svg>

When to Use Each Consistency Model

Use Eventual Consistency When:

High throughput is priority

// Social media feed - eventual consistency acceptable
const feedPosts = await dynamodb.query({
  TableName: 'Posts',
  IndexName: 'UserFeedIndex',
  KeyConditionExpression: 'userId = :uid',
  ExpressionAttributeValues: {
    ':uid': '12345'
  },
  ConsistentRead: false,  // Eventual consistency
  Limit: 50
}).promise();

Cost optimization

// Analytics queries - eventual consistency for cost savings
const metrics = await dynamodb.query({
  TableName: 'AnalyticsEvents',
  KeyConditionExpression: 'eventType = :type AND #ts BETWEEN :start AND :end',
  ExpressionAttributeNames: {
    '#ts': 'timestamp'
  },
  ExpressionAttributeValues: {
    ':type': 'PAGE_VIEW',
    ':start': '2024-01-01',
    ':end': '2024-01-31'
  },
  ConsistentRead: false
}).promise();

Reading from GSIs

// GSI reads - only eventual consistency available
const usersByEmail = await dynamodb.query({
  TableName: 'Users',
  IndexName: 'EmailIndex',
  KeyConditionExpression: 'email = :email',
  ExpressionAttributeValues: {
    ':email': 'john@example.com'
  }
  // ConsistentRead not supported on GSIs
}).promise();

Caching scenarios

// Product catalog - slight staleness acceptable
const products = await dynamodb.query({
  TableName: 'Products',
  IndexName: 'CategoryIndex',
  KeyConditionExpression: 'category = :cat',
  ExpressionAttributeValues: {
    ':cat': 'Electronics'
  },
  ConsistentRead: false
}).promise();

Use Strong Consistency When:

Financial transactions

// Account balance - must be accurate
const account = await dynamodb.get({
  TableName: 'Accounts',
  Key: { accountId: 'A12345' },
  ConsistentRead: true  // Strong consistency required
}).promise();

// Ensure latest balance before debit
if (account.Item.balance >= withdrawalAmount) {
  await processWithdrawal();
}

Inventory management

// Stock levels - prevent overselling
const product = await dynamodb.get({
  TableName: 'Inventory',
  Key: { productId: 'PROD-789' },
  ConsistentRead: true
}).promise();

if (product.Item.quantity >= orderQuantity) {
  await reserveInventory();
}

Read-after-write scenarios

// Create order then immediately display
await dynamodb.put({
  TableName: 'Orders',
  Item: { orderId: 'ORD-001', status: 'PENDING' }
}).promise();

// Read immediately with strong consistency
const order = await dynamodb.get({
  TableName: 'Orders',
  Key: { orderId: 'ORD-001' },
  ConsistentRead: true
}).promise();

return order.Item;  // Guaranteed to show 'PENDING' status

Critical data verification

// User authentication - must have latest credentials
const user = await dynamodb.get({
  TableName: 'Users',
  Key: { userId: '12345' },
  ConsistentRead: true
}).promise();

// Verify password against latest hash
const isValid = await verifyPassword(
  inputPassword,
  user.Item.passwordHash
);

Consistency in Distributed Scenarios

Multi-Region Considerations

When using DynamoDB Global Tables, additional consistency considerations apply:

// Global Tables provide eventual consistency across regions
// Writes in us-east-1
await dynamodbUSEast.put({
  TableName: 'GlobalUsers',
  Item: { userId: '12345', region: 'us-east-1', lastUpdate: Date.now() }
}).promise();

// Read in eu-west-1 (may not immediately see write)
const user = await dynamodbEUWest.get({
  TableName: 'GlobalUsers',
  Key: { userId: '12345' }
}).promise();

// Typical propagation: < 1 second
// During network partitions: may take longer

Global Table Consistency Timeline:

<svg viewBox="0 0 900 400" xmlns="http://www.w3.org/2000/svg">
  <!-- Title -->
  <text x="450" y="30" font-size="18" font-weight="bold" text-anchor="middle" fill="#333">
    Global Tables Cross-Region Replication
  </text>

  <!-- Timeline -->
  <line x1="100" y1="200" x2="800" y2="200" stroke="#333" stroke-width="2"/>

  <!-- Time markers -->
  <text x="100" y="230" font-size="12" text-anchor="middle" fill="#666">T0</text>
  <text x="250" y="230" font-size="12" text-anchor="middle" fill="#666">T1</text>
  <text x="400" y="230" font-size="12" text-anchor="middle" fill="#666">T2</text>
  <text x="550" y="230" font-size="12" text-anchor="middle" fill="#666">T3</text>
  <text x="700" y="230" font-size="12" text-anchor="middle" fill="#666">T4</text>

  <!-- US East Region -->
  <rect x="50" y="60" width="200" height="100" fill="#e3f2fd" stroke="#1976d2" stroke-width="2" rx="5"/>
  <text x="150" y="85" font-size="14" font-weight="bold" text-anchor="middle" fill="#1976d2">
    us-east-1
  </text>
  <text x="150" y="110" font-size="12" text-anchor="middle" fill="#333">
    Write: balance = 500
  </text>
  <text x="150" y="130" font-size="11" text-anchor="middle" fill="#666">
    T0: Write initiated
  </text>
  <text x="150" y="145" font-size="11" text-anchor="middle" fill="#666">
    T1: Write acknowledged
  </text>

  <!-- EU West Region -->
  <rect x="300" y="60" width="200" height="100" fill="#fff3e0" stroke="#ff9800" stroke-width="2" rx="5"/>
  <text x="400" y="85" font-size="14" font-weight="bold" text-anchor="middle" fill="#ff9800">
    eu-west-1
  </text>
  <text x="400" y="110" font-size="12" text-anchor="middle" fill="#333">
    Read: balance = ?
  </text>
  <text x="400" y="130" font-size="11" text-anchor="middle" fill="#666">
    T1: Old value (300)
  </text>
  <text x="400" y="145" font-size="11" text-anchor="middle" fill="#666">
    T3: New value (500)
  </text>

  <!-- AP South Region -->
  <rect x="550" y="60" width="200" height="100" fill="#e8f5e9" stroke="#4caf50" stroke-width="2" rx="5"/>
  <text x="650" y="85" font-size="14" font-weight="bold" text-anchor="middle" fill="#4caf50">
    ap-south-1
  </text>
  <text x="650" y="110" font-size="12" text-anchor="middle" fill="#333">
    Read: balance = ?
  </text>
  <text x="650" y="130" font-size="11" text-anchor="middle" fill="#666">
    T2: Old value (300)
  </text>
  <text x="650" y="145" font-size="11" text-anchor="middle" fill="#666">
    T4: New value (500)
  </text>

  <!-- Replication arrows -->
  <path d="M 250 120 L 300 120" stroke="#1976d2" stroke-width="2" fill="none" marker-end="url(#arrowhead)" stroke-dasharray="5,5"/>
  <path d="M 250 140 L 550 140" stroke="#1976d2" stroke-width="2" fill="none" marker-end="url(#arrowhead)" stroke-dasharray="5,5"/>

  <!-- Info Box -->
  <rect x="200" y="280" width="500" height="80" fill="#fff9c4" stroke="#fbc02d" stroke-width="2" rx="5"/>
  <text x="450" y="310" font-size="13" font-weight="bold" text-anchor="middle" fill="#333">
    Cross-Region Replication Latency
  </text>
  <text x="450" y="335" font-size="12" text-anchor="middle" fill="#666">
    Typical: 0.5-1 second | During partition: Several seconds
  </text>
  <text x="450" y="355" font-size="11" text-anchor="middle" fill="#666">
    Last-writer-wins conflict resolution with timestamps
  </text>

  <!-- Arrow marker -->
  <defs>
    <marker id="arrowhead" markerWidth="10" markerHeight="10" refX="9" refY="3" orient="auto">
      <polygon points="0 0, 10 3, 0 6" fill="#1976d2"/>
    </marker>
  </defs>
</svg>

Conflict Resolution

In multi-region setups, DynamoDB uses last-writer-wins based on timestamps:

// Concurrent writes to same item in different regions

// us-east-1 at T0
await dynamodbUSEast.update({
  TableName: 'GlobalUsers',
  Key: { userId: '12345' },
  UpdateExpression: 'SET #name = :name',
  ExpressionAttributeNames: { '#name': 'name' },
  ExpressionAttributeValues: { ':name': 'Alice' }
}).promise();

// eu-west-1 at T0 + 50ms
await dynamodbEUWest.update({
  TableName: 'GlobalUsers',
  Key: { userId: '12345' },
  UpdateExpression: 'SET #name = :name',
  ExpressionAttributeNames: { '#name': 'name' },
  ExpressionAttributeValues: { ':name': 'Bob' }
}).promise();

// Result after replication:
// Last write wins (T0 + 50ms): name = 'Bob'

// To handle conflicts, use version numbers:
await dynamodbUSEast.update({
  TableName: 'GlobalUsers',
  Key: { userId: '12345' },
  UpdateExpression: 'SET #name = :name, #version = :version',
  ConditionExpression: '#version = :currentVersion',
  ExpressionAttributeNames: {
    '#name': 'name',
    '#version': 'version'
  },
  ExpressionAttributeValues: {
    ':name': 'Alice',
    ':version': 2,
    ':currentVersion': 1
  }
}).promise();

Application-Level Consistency Patterns

Pattern 1: Optimistic Locking

Use version numbers to prevent lost updates:

// Read current version
const user = await dynamodb.get({
  TableName: 'Users',
  Key: { userId: '12345' },
  ConsistentRead: true
}).promise();

const currentVersion = user.Item.version;

// Update with version check
try {
  await dynamodb.update({
    TableName: 'Users',
    Key: { userId: '12345' },
    UpdateExpression: 'SET #name = :name, #version = :newVersion',
    ConditionExpression: '#version = :currentVersion',
    ExpressionAttributeNames: {
      '#name': 'name',
      '#version': 'version'
    },
    ExpressionAttributeValues: {
      ':name': 'Updated Name',
      ':newVersion': currentVersion + 1,
      ':currentVersion': currentVersion
    }
  }).promise();

  console.log('Update successful');
} catch (error) {
  if (error.code === 'ConditionalCheckFailedException') {
    console.log('Version conflict - retry');
    // Retry with fresh read
  }
}

Pattern 2: Idempotent Writes

Use client tokens to prevent duplicate writes:

// Idempotent payment processing
const processPayment = async (paymentId, amount) => {
  try {
    await dynamodb.put({
      TableName: 'Payments',
      Item: {
        paymentId: paymentId,  // Unique ID from client
        amount: amount,
        status: 'COMPLETED',
        timestamp: new Date().toISOString()
      },
      ConditionExpression: 'attribute_not_exists(paymentId)'
    }).promise();

    return { success: true, message: 'Payment processed' };
  } catch (error) {
    if (error.code === 'ConditionalCheckFailedException') {
      // Payment already exists - idempotent success
      return { success: true, message: 'Payment already processed' };
    }
    throw error;
  }
};

// Client can safely retry
await processPayment('PAY-12345', 99.99);  // First call
await processPayment('PAY-12345', 99.99);  // Retry - no duplicate charge

Pattern 3: Event Sourcing

Store events immutably for eventual consistency:

// Append-only event log
const addEvent = async (aggregateId, event) => {
  await dynamodb.put({
    TableName: 'EventStore',
    Item: {
      aggregateId: aggregateId,
      eventId: `${Date.now()}-${randomUUID()}`,
      eventType: event.type,
      eventData: event.data,
      timestamp: new Date().toISOString()
    }
  }).promise();
};

// Rebuild state from events
const getAggregateState = async (aggregateId) => {
  const events = await dynamodb.query({
    TableName: 'EventStore',
    KeyConditionExpression: 'aggregateId = :id',
    ExpressionAttributeValues: {
      ':id': aggregateId
    },
    ConsistentRead: false  // Eventual consistency acceptable
  }).promise();

  // Apply events to rebuild state
  return events.Items.reduce((state, event) => {
    return applyEvent(state, event);
  }, initialState);
};

Pattern 4: CQRS (Command Query Responsibility Segregation)

Separate read and write models:

// Write model - strong consistency
const createOrder = async (order) => {
  await dynamodb.put({
    TableName: 'Orders',
    Item: {
      orderId: order.id,
      userId: order.userId,
      status: 'PENDING',
      items: order.items,
      total: order.total,
      createdAt: new Date().toISOString()
    }
  }).promise();

  // Emit event for read model update
  await eventBus.publish({
    type: 'ORDER_CREATED',
    data: order
  });
};

// Read model - eventual consistency (optimized for queries)
const getOrderHistory = async (userId) => {
  return await dynamodb.query({
    TableName: 'OrderHistory',  // Separate read-optimized table
    IndexName: 'UserOrdersIndex',
    KeyConditionExpression: 'userId = :userId',
    ExpressionAttributeValues: {
      ':userId': userId
    },
    ConsistentRead: false,  // Eventual consistency for performance
    ScanIndexForward: false
  }).promise();
};

// Event handler updates read model
const handleOrderCreated = async (event) => {
  await dynamodb.put({
    TableName: 'OrderHistory',
    Item: {
      userId: event.data.userId,
      orderId: event.data.id,
      orderDate: event.data.createdAt,
      total: event.data.total,
      status: event.data.status
    }
  }).promise();
};

Consistency Monitoring

Detecting Consistency Issues

// Monitor consistency lag
const monitorConsistency = async (itemId) => {
  const writeTimestamp = Date.now();

  // Write with timestamp
  await dynamodb.put({
    TableName: 'TestItems',
    Item: {
      itemId: itemId,
      writeTimestamp: writeTimestamp,
      value: 'test-value'
    }
  }).promise();

  // Immediate eventual read
  const eventualRead = await dynamodb.get({
    TableName: 'TestItems',
    Key: { itemId: itemId },
    ConsistentRead: false
  }).promise();

  const eventualLag = Date.now() - (eventualRead.Item?.writeTimestamp || writeTimestamp);

  // Strong read
  const strongRead = await dynamodb.get({
    TableName: 'TestItems',
    Key: { itemId: itemId },
    ConsistentRead: true
  }).promise();

  const strongLag = Date.now() - strongRead.Item.writeTimestamp;

  return {
    eventualConsistencyLag: eventualLag,
    strongConsistencyLag: strongLag,
    eventualFoundData: !!eventualRead.Item,
    strongFoundData: !!strongRead.Item
  };
};

// Run monitoring
const metrics = await monitorConsistency('test-123');
console.log('Eventual lag:', metrics.eventualConsistencyLag, 'ms');
console.log('Strong lag:', metrics.strongConsistencyLag, 'ms');

CloudWatch Metrics

// Monitor read consistency choices
const AWS = require('aws-sdk');
const cloudwatch = new AWS.CloudWatch();

const trackConsistencyMetrics = async (operation, consistencyType) => {
  await cloudwatch.putMetricData({
    Namespace: 'DynamoDB/Consistency',
    MetricData: [
      {
        MetricName: 'ReadOperations',
        Dimensions: [
          { Name: 'Operation', Value: operation },
          { Name: 'ConsistencyType', Value: consistencyType }
        ],
        Value: 1,
        Unit: 'Count',
        Timestamp: new Date()
      }
    ]
  }).promise();
};

// Track in your application
const getUser = async (userId, strongConsistency = false) => {
  await trackConsistencyMetrics('GetUser', strongConsistency ? 'Strong' : 'Eventual');

  return await dynamodb.get({
    TableName: 'Users',
    Key: { userId: userId },
    ConsistentRead: strongConsistency
  }).promise();
};

Interview Questions and Answers

Question 1: Explain the difference between eventual consistency and strong consistency in DynamoDB.

Answer: Eventual Consistency (default):

Reads may return stale data immediately after writes
Data becomes consistent typically within one second
Reads from any of the three replicas
Consumes half the RCUs (0.5 RCU per 4KB read)
Best for high throughput and cost optimization
Example: Social media feeds, analytics

Strong Consistency:

Always returns the most recent data
Reads coordinate across replicas to ensure latest value
Consumes double the RCUs (1 RCU per 4KB read)
Slightly higher latency due to coordination
Best for critical data accuracy
Example: Financial transactions, inventory

Key trade-off: Performance and cost vs. data freshness

Question 2: Can you use strong consistency with Global Secondary Indexes?

Answer: No. GSIs only support eventually consistent reads. Reason: GSIs are asynchronously updated from the base table. The propagation from base table to GSI typically takes milliseconds but is not instantaneous. Workaround:

// If you need strong consistency for a GSI query pattern
// Option 1: Query base table with strong consistency if possible
const result = await dynamodb.get({
  TableName: 'Users',
  Key: { userId: userId },  // Base table key
  ConsistentRead: true
}).promise();

// Option 2: Accept eventual consistency and design for it
const gsiResult = await dynamodb.query({
  TableName: 'Users',
  IndexName: 'EmailIndex',
  KeyConditionExpression: 'email = :email',
  ExpressionAttributeValues: { ':email': email }
  // ConsistentRead not available
}).promise();

// Option 3: Use optimistic locking with version numbers
// to detect stale reads

Question 3: How does DynamoDB handle consistency in multi-region Global Tables?

Answer: Consistency Model: Global Tables provide eventual consistency across regions with last-writer-wins conflict resolution. How it works:

Writes succeed in the local region immediately
Changes replicate asynchronously to other regions
Typical replication latency: < 1 second
During conflicts, timestamp determines winner

Example:

// us-east-1: Write at T0
write(userId: '123', name: 'Alice', timestamp: T0)

// eu-west-1: Write at T0 + 50ms
write(userId: '123', name: 'Bob', timestamp: T0 + 50ms)

// Final state after replication:
// name = 'Bob' (later timestamp wins)

Handling conflicts:

Use version numbers for optimistic locking
Design idempotent operations
Implement application-level conflict resolution
Consider region affinity for related writes

Question 4: What is read-after-write consistency and when does DynamoDB provide it?

Answer: Read-after-write consistency guarantees that a read immediately following a write will see that write. DynamoDB provides this for:

GetItem/Query on the same partition key immediately after PutItem/UpdateItem
Within the same request thread/session
TransactGetItems following TransactWriteItems

Example:

// Write
await dynamodb.put({
  TableName: 'Users',
  Item: { userId: '123', name: 'Alice' }
}).promise();

// Immediate read (read-after-write consistency)
const user = await dynamodb.get({
  TableName: 'Users',
  Key: { userId: '123' }
}).promise();
// Guaranteed to return name: 'Alice'

Not provided for:

GSI reads (eventual only)
Different client sessions
BatchGetItem operations

Question 5: How would you implement a bank account system requiring strong consistency?

Answer:

class BankAccountService {
  async transfer(fromAccount, toAccount, amount) {
    // Use transactions for atomicity and consistency
    try {
      await dynamodb.transactWrite({
        TransactItems: [
          {
            // Debit from account
            Update: {
              TableName: 'Accounts',
              Key: { accountId: fromAccount },
              UpdateExpression: 'SET balance = balance - :amount, version = version + :inc',
              ConditionExpression: 'balance >= :amount AND version = :currentVersion',
              ExpressionAttributeValues: {
                ':amount': amount,
                ':inc': 1,
                ':currentVersion': await this.getVersion(fromAccount)
              }
            }
          },
          {
            // Credit to account
            Update: {
              TableName: 'Accounts',
              Key: { accountId: toAccount },
              UpdateExpression: 'SET balance = balance + :amount, version = version + :inc',
              ExpressionAttributeValues: {
                ':amount': amount,
                ':inc': 1
              }
            }
          }
        ]
      }).promise();

      return { success: true };
    } catch (error) {
      if (error.code === 'TransactionCanceledException') {
        return { success: false, reason: 'Insufficient funds or version conflict' };
      }
      throw error;
    }
  }

  async getBalance(accountId) {
    // Always use strong consistency for balance reads
    const result = await dynamodb.get({
      TableName: 'Accounts',
      Key: { accountId: accountId },
      ConsistentRead: true  // Critical for accurate balance
    }).promise();

    return result.Item.balance;
  }

  async getVersion(accountId) {
    const result = await dynamodb.get({
      TableName: 'Accounts',
      Key: { accountId: accountId },
      ProjectionExpression: 'version',
      ConsistentRead: true
    }).promise();

    return result.Item.version;
  }
}

Key points:

Use transactions for atomic multi-item updates
Always use strong consistency for balance reads
Implement version numbers for optimistic locking
Use conditional expressions to prevent invalid states

Question 6: What are the cost implications of using strong consistency?

Answer: Read Capacity Units (RCUs):

Eventual consistency: 0.5 RCU per 4KB read
Strong consistency: 1 RCU per 4KB read
Cost difference: 2x more expensive

Example calculation:

// Scenario: 1 million reads per day, 1KB average item size

// Eventual consistency
const eventualRCUs = 1_000_000 * 0.5 * (1/4) = 125,000 RCUs
const eventualCost = (125_000 / 1_000_000) * $0.25 = $0.03 per day

// Strong consistency
const strongRCUs = 1_000_000 * 1 * (1/4) = 250,000 RCUs
const strongCost = (250_000 / 1_000_000) * $0.25 = $0.06 per day

// Monthly difference: ~$0.90 for this workload

Recommendations:

Use eventual consistency by default
Reserve strong consistency for critical operations
Monitor your consistency usage patterns
Consider caching for frequently read data

Question 7: How do you test consistency behavior in your application?

Answer:

const testConsistencyBehavior = async () => {
  const testId = `test-${Date.now()}`;

  // Test 1: Write and immediate eventual read
  await dynamodb.put({
    TableName: 'TestTable',
    Item: { id: testId, value: 'initial', timestamp: Date.now() }
  }).promise();

  const eventualRead = await dynamodb.get({
    TableName: 'TestTable',
    Key: { id: testId },
    ConsistentRead: false
  }).promise();

  console.log('Eventual read found data:', !!eventualRead.Item);

  // Test 2: Write and immediate strong read
  const strongRead = await dynamodb.get({
    TableName: 'TestTable',
    Key: { id: testId },
    ConsistentRead: true
  }).promise();

  console.log('Strong read found data:', !!strongRead.Item);

  // Test 3: Update and concurrent reads
  await dynamodb.update({
    TableName: 'TestTable',
    Key: { id: testId },
    UpdateExpression: 'SET #value = :value',
    ExpressionAttributeNames: { '#value': 'value' },
    ExpressionAttributeValues: { ':value': 'updated' }
  }).promise();

  // Race condition test
  const [eventual1, eventual2, strong] = await Promise.all([
    dynamodb.get({ TableName: 'TestTable', Key: { id: testId }, ConsistentRead: false }).promise(),
    dynamodb.get({ TableName: 'TestTable', Key: { id: testId }, ConsistentRead: false }).promise(),
    dynamodb.get({ TableName: 'TestTable', Key: { id: testId }, ConsistentRead: true }).promise()
  ]);

  console.log({
    eventual1: eventual1.Item?.value,
    eventual2: eventual2.Item?.value,
    strong: strong.Item?.value
  });

  // Test 4: GSI consistency lag
  const writeTime = Date.now();
  await dynamodb.put({
    TableName: 'TestTable',
    Item: {
      id: testId,
      value: 'test',
      gsiKey: 'indexed-value',
      timestamp: writeTime
    }
  }).promise();

  let gsiFound = false;
  let attempts = 0;
  const maxAttempts = 10;

  while (!gsiFound && attempts < maxAttempts) {
    const gsiResult = await dynamodb.query({
      TableName: 'TestTable',
      IndexName: 'GSI1',
      KeyConditionExpression: 'gsiKey = :key',
      ExpressionAttributeValues: { ':key': 'indexed-value' }
    }).promise();

    gsiFound = gsiResult.Items.length > 0;
    if (!gsiFound) {
      await new Promise(resolve => setTimeout(resolve, 100));
    }
    attempts++;
  }

  console.log('GSI propagation took', attempts * 100, 'ms');
};

Question 8: Explain the CAP theorem and how DynamoDB fits into it.

Answer: CAP Theorem: In a distributed system, you can guarantee at most two of:

Consistency: All nodes see the same data
Availability: Every request gets a response
Partition tolerance: System works despite network failures

DynamoDB’s choice: AP (Availability + Partition Tolerance) Why:

Availability is critical for most applications
Network partitions are inevitable in distributed systems
Partition tolerance is non-negotiable

How DynamoDB handles it:

Prioritizes availability during network partitions
Offers eventual consistency by default (favors A over C)
Provides strong consistency as an option (temporarily favors C)
Uses quorum-based replication (write to 2 of 3 replicas)

Example during partition:

Normal operation:
Write → [AZ1, AZ2, AZ3] → Success (2 of 3 ACKs required)

Network partition (AZ3 isolated):
Write → [AZ1, AZ2] → Success (still 2 of 3)
Read from AZ1/AZ2 → Consistent
Read from AZ3 → Potentially stale (eventual consistency)

Strong consistency read → Routes to AZ1 or AZ2 (majority)

Trade-off: Slight staleness (< 1s) for high availability

Question 9: How would you design a system that needs both high throughput and strong consistency?

Answer: Strategy: Hybrid approach using CQRS pattern

// Write path - Strong consistency where needed
class WriteService {
  async createOrder(order) {
    // Critical write with transaction
    await dynamodb.transactWrite({
      TransactItems: [
        {
          // Decrement inventory
          Update: {
            TableName: 'Inventory',
            Key: { productId: order.productId },
            UpdateExpression: 'SET quantity = quantity - :qty',
            ConditionExpression: 'quantity >= :qty',
            ExpressionAttributeValues: { ':qty': order.quantity }
          }
        },
        {
          // Create order
          Put: {
            TableName: 'Orders',
            Item: {
              orderId: order.id,
              userId: order.userId,
              status: 'PENDING',
              createdAt: new Date().toISOString()
            }
          }
        }
      ]
    }).promise();

    // Async: Update read-optimized denormalized view
    await eventBus.publish({
      type: 'ORDER_CREATED',
      data: order
    });

    return order;
  }
}

// Read path - Eventual consistency for performance
class ReadService {
  async getOrderHistory(userId) {
    // High-throughput eventual consistent reads
    return await dynamodb.query({
      TableName: 'OrderHistory',  // Denormalized table
      KeyConditionExpression: 'userId = :userId',
      ExpressionAttributeValues: { ':userId': userId },
      ConsistentRead: false,  // Eventual for performance
      Limit: 100
    }).promise();
  }

  async getOrderDetails(orderId) {
    // Strong consistency for critical views
    return await dynamodb.get({
      TableName: 'Orders',
      Key: { orderId: orderId },
      ConsistentRead: true  // Strong for accuracy
    }).promise();
  }
}

// Caching layer for ultra-high throughput
class CachedReadService {
  constructor() {
    this.cache = new Redis();
  }

  async getProduct(productId) {
    // Check cache first
    const cached = await this.cache.get(`product:${productId}`);
    if (cached) {
      return JSON.parse(cached);
    }

    // Cache miss - read from DynamoDB
    const product = await dynamodb.get({
      TableName: 'Products',
      Key: { productId: productId },
      ConsistentRead: false  // Eventual for caching
    }).promise();

    // Cache for 5 minutes
    await this.cache.setex(
      `product:${productId}`,
      300,
      JSON.stringify(product.Item)
    );

    return product.Item;
  }
}

Key techniques:

Use strong consistency only where critical (orders, inventory)
Use eventual consistency for high-throughput reads (history, analytics)
Implement caching for frequently accessed data
Separate read and write models (CQRS)
Use denormalization to reduce need for strong consistency

Question 10: What happens if you write to DynamoDB and immediately read from a GSI?

Answer: Short answer: The read might not see the write immediately. Detailed explanation: Write to base table:

// T0: Write to base table
await dynamodb.put({
  TableName: 'Users',
  Item: {
    userId: '123',
    email: 'alice@example.com',
    name: 'Alice'
  }
}).promise();
// T1: Write acknowledged

// T1: Immediately query GSI
const result = await dynamodb.query({
  TableName: 'Users',
  IndexName: 'EmailIndex',
  KeyConditionExpression: 'email = :email',
  ExpressionAttributeValues: {
    ':email': 'alice@example.com'
  }
}).promise();

// Result: Might be empty! GSI not yet updated

Timeline:

T0: Base table write initiated
T1: Base table write acknowledged
T2: GSI asynchronously updated (typically < 100ms)
T3: GSI read sees the data

Query at T1.5: Empty (GSI not updated)
Query at T3: Returns data (GSI updated)

Solutions:

Design for eventual consistency:

const createUser = async (user) => {
  await dynamodb.put({ TableName: 'Users', Item: user }).promise();

  // Return user directly, don't query GSI
  return user;
};

Use base table for immediate reads:

const createUser = async (user) => {
  await dynamodb.put({ TableName: 'Users', Item: user }).promise();

  // Read from base table with strong consistency
  return await dynamodb.get({
    TableName: 'Users',
    Key: { userId: user.userId },
    ConsistentRead: true
  }).promise();
};

Retry with exponential backoff:

const findUserByEmail = async (email, maxRetries = 3) => {
  for (let i = 0; i < maxRetries; i++) {
    const result = await dynamodb.query({
      TableName: 'Users',
      IndexName: 'EmailIndex',
      KeyConditionExpression: 'email = :email',
      ExpressionAttributeValues: { ':email': email }
    }).promise();

    if (result.Items.length > 0) {
      return result.Items[0];
    }

    // Wait before retry
    await new Promise(resolve => setTimeout(resolve, 100 * Math.pow(2, i)));
  }

  throw new Error('User not found after retries');
};

Summary

Key Takeaways:

Consistency Models:
- Eventual consistency: Default, cheaper, higher throughput
- Strong consistency: Opt-in, more expensive, guaranteed fresh data
When to Use What:
- Eventual: Analytics, caching, high-throughput scenarios
- Strong: Financial data, inventory, critical operations
Limitations:
- GSIs only support eventual consistency
- Global Tables use eventual consistency across regions
- BatchGetItem doesn’t support strong consistency
Best Practices:
- Use eventual consistency by default
- Reserve strong consistency for critical paths
- Implement application-level consistency (versioning, idempotency)
- Monitor consistency metrics
Patterns:
- Optimistic locking for conflict detection
- CQRS for separating read/write models
- Event sourcing for audit trails
- Caching for ultra-high throughput

Understanding consistency models is crucial for building correct, performant, and cost-effective DynamoDB applications.

​Chapter 4: Consistency Models in DynamoDB

​Introduction

​Understanding Distributed Consistency

​The CAP Theorem

​Replication in DynamoDB

​DynamoDB Consistency Models

​Eventual Consistency (Default)

​Strong Consistency

​Read-After-Write Consistency

​Consistency Across Operations

​GetItem and Query Operations

​Scan Operations

​BatchGetItem

​Global Secondary Indexes

​Transactions

​Consistency Trade-offs

​When to Use Each Consistency Model

​Use Eventual Consistency When:

​Use Strong Consistency When:

​Consistency in Distributed Scenarios

​Multi-Region Considerations

​Conflict Resolution

​Application-Level Consistency Patterns

​Pattern 1: Optimistic Locking

​Pattern 2: Idempotent Writes

​Pattern 3: Event Sourcing

​Pattern 4: CQRS (Command Query Responsibility Segregation)

​Consistency Monitoring

​Detecting Consistency Issues

​CloudWatch Metrics

​Interview Questions and Answers

​Question 1: Explain the difference between eventual consistency and strong consistency in DynamoDB.

​Question 2: Can you use strong consistency with Global Secondary Indexes?

​Question 3: How does DynamoDB handle consistency in multi-region Global Tables?

​Question 4: What is read-after-write consistency and when does DynamoDB provide it?

​Question 5: How would you implement a bank account system requiring strong consistency?

​Question 6: What are the cost implications of using strong consistency?

​Question 7: How do you test consistency behavior in your application?

​Question 8: Explain the CAP theorem and how DynamoDB fits into it.

​Question 9: How would you design a system that needs both high throughput and strong consistency?

​Question 10: What happens if you write to DynamoDB and immediately read from a GSI?

​Summary