DynamoDB Consistency

• AWS has a Region, which is a physical location around the world where we cluster data centers, with one or more Availability Zones which are discrete data centers with redundant power, networking, and connectivity in an AWS Region.
• Amazon automatically stores each DynamoDB table in the three geographically distributed locations or AZs for durability.
• DynamoDB consistency represents the manner and timing in which the successful write or update of a data item is reflected in a subsequent read operation of that same item.

DynamoDB Consistency Modes

Eventually Consistent Reads (Default)

• Eventual consistency option maximizes the read throughput.
• Consistency across all copies is usually reached within a second.
• However, an eventually consistent read might not reflect the results of a recently completed write.
• Repeating a read after a short time should return the updated data.
• DynamoDB uses eventually consistent reads, by default.
• Use Cases:
  • Applications that can tolerate reading slightly stale data.
  • Read-heavy workloads where throughput is more important than immediate consistency.
  • Cost-sensitive applications (eventually consistent reads are half the cost of strongly consistent reads).

Strongly Consistent Reads

• Strongly consistent read returns a result that reflects all writes that received a successful response prior to the read.
• Ensures that the most up-to-date data is returned.
• Cost: Strongly consistent reads are 2x the cost of eventually consistent reads (consume twice the read capacity units).
• Disadvantages:
  • A strongly consistent read might not be available if there is a network delay or outage. In this case, DynamoDB may return a server error (HTTP 500).
  • Strongly consistent reads may have higher latency than eventually consistent reads.
  • Not supported on Global Secondary Indexes (GSIs) – only eventually consistent reads are supported on GSIs.
  • Strongly consistent reads use more throughput capacity than eventually consistent reads.
• Use Cases:
  • Applications requiring immediate read-after-write consistency.
  • Financial transactions or inventory management where stale data is unacceptable.
  • Scenarios where data accuracy is critical.

Specifying Consistency Mode

• DynamoDB allows the user to specify whether the read should be eventually consistent or strongly consistent at the time of the request.
• Read operations (such as GetItem, Query, and Scan) provide a ConsistentRead parameter. If set to true, DynamoDB uses strongly consistent reads during the operation.
• Default Behavior: Query, GetItem, and BatchGetItem operations perform eventually consistent reads by default.
• Forcing Strong Consistency:
  • Query and GetItem operations can be forced to be strongly consistent by setting ConsistentRead=true.
  • Query operations cannot perform strongly consistent reads on Global Secondary Indexes (GSIs).
  • BatchGetItem operations can be forced to be strongly consistent on a per-table basis.
  • Scan operations can be forced to be strongly consistent.

Transactional Consistency

• DynamoDB supports transactions with full ACID (Atomicity, Consistency, Isolation, Durability) properties.
• Transactions provide all-or-nothing execution for multiple operations across one or more tables.
• Transaction Operations:
  • TransactWriteItems – Perform multiple write operations atomically.
  • TransactGetItems – Perform multiple read operations with snapshot isolation.
• Consistency Guarantees:
  • Atomicity: All operations in a transaction succeed or fail together.
  • Consistency: Transactions move the database from one valid state to another.
  • Isolation: Transactions are isolated from each other using snapshot isolation.
  • Durability: Once a transaction is committed, it is durable.
• Regional Scope: Transactional operations provide ACID guarantees within a single Region.
• Global Tables Consideration: For Global Tables with MREC, transactions are only atomic within the Region where invoked (not replicated as a unit).
• Cost: Transactional operations consume 2x the write capacity units compared to standard writes.

Multi-Region Strong Consistency (MRSC) – January 2025

• Announced at AWS re:Invent 2024 and generally available in January 2025.
• Available for DynamoDB Global Tables configured with Multi-Region Strong Consistency mode.
• Capability: Provides strong consistency across multiple AWS Regions.
• Guarantee: Strongly consistent reads on an MRSC table always return the latest version of an item, irrespective of the Region where the read is performed.
• Zero RPO: Enables Recovery Point Objective (RPO) of zero for highest resilience.
• How It Works:
  • Item changes are synchronously replicated to at least one other Region before the write operation returns success.
  • Strongly consistent reads always reflect the latest committed write across all Regions.
  • Conditional writes always evaluate against the latest version of an item globally.
• Deployment Requirements:
  • Must be deployed in exactly three Regions.
  • Can configure with 3 replicas OR 2 replicas + 1 witness.
  • Available in three Region sets: US, EU, and AP (cannot span Region sets).
• Trade-offs:
  • Higher write latency compared to MREC (eventual consistency) due to synchronous replication.
  • Higher strongly consistent read latency compared to MREC.
• Use Cases:
  • Financial applications requiring global strong consistency.
  • Inventory management systems across multiple Regions.
  • Applications requiring zero data loss (RPO = 0).
  • Compliance scenarios requiring strict consistency guarantees.
• Limitations:
  • Transactions not supported on MRSC tables.
  • TTL not supported on MRSC tables.
  • Local Secondary Indexes not supported on MRSC tables.

Consistency Comparison

Best Practices

• Default to Eventually Consistent: Use eventually consistent reads by default for cost and performance optimization.
• Use Strong Consistency Selectively: Only use strongly consistent reads when immediate consistency is required.
• Avoid Strong Consistency on GSIs: Design data models to avoid needing strongly consistent reads on GSIs (not supported).
• Consider Read-After-Write Patterns: If your application writes and immediately reads, use strongly consistent reads or implement retry logic.
• Use Transactions for Multi-Item Operations: When multiple items must be updated atomically, use transactions.
• Evaluate MRSC for Global Applications: For applications requiring global strong consistency, consider MRSC Global Tables.
• Monitor Consistency Metrics: Use CloudWatch to monitor read/write patterns and adjust consistency settings accordingly.
• Handle Errors Gracefully: Implement retry logic for strongly consistent reads that may fail during network issues.

AWS Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. Which of the following statements is true about DynamoDB?
   1. Requests are eventually consistent unless otherwise specified.
   2. Requests are strongly consistent.
   3. Tables do not contain primary keys.
   4. None of the above
2. How is provisioned throughput affected by the chosen consistency model when reading data from a DynamoDB table?
   1. Strongly consistent reads use the same amount of throughput as eventually consistent reads
   2. Strongly consistent reads use variable throughput depending on read activity
   3. Strongly consistent reads use more throughput than eventually consistent reads.
   4. Strongly consistent reads use less throughput than eventually consistent reads
3. A company needs to perform a query on a Global Secondary Index (GSI) and requires the most up-to-date data. What consistency mode should they use?
   1. Strongly consistent reads
   2. Eventually consistent reads (GSIs do not support strongly consistent reads)
   3. Transactional reads
   4. Multi-Region strong consistency
4. A financial application requires strong consistency across multiple AWS Regions with zero data loss (RPO = 0). Which DynamoDB feature should they use?
   1. DynamoDB Global Tables with MREC (eventual consistency)
   2. DynamoDB Global Tables with MRSC (multi-Region strong consistency)
   3. DynamoDB with strongly consistent reads
   4. DynamoDB transactions
5. A developer needs to update multiple items across two DynamoDB tables atomically. Which feature should they use?
   1. Strongly consistent writes
   2. BatchWriteItem operation
   3. DynamoDB transactions (TransactWriteItems)
   4. Conditional writes
6. What is the cost difference between eventually consistent reads and strongly consistent reads in DynamoDB?
   1. No difference in cost
   2. Strongly consistent reads cost 2x more (consume 2x RCU)
   3. Strongly consistent reads cost 3x more
   4. Eventually consistent reads cost 2x more
7. Which of the following statements about DynamoDB consistency are correct? (Select TWO)
   1. Eventually consistent reads are the default for Query and GetItem operations.
   2. Strongly consistent reads are supported on Global Secondary Indexes.
   3. Strongly consistent reads may return HTTP 500 errors during network issues.
   4. Transactions provide ACID guarantees across multiple Regions.
   5. MRSC Global Tables support local secondary indexes.

References

• Read consistency in DynamoDB
• Multi-Region strong consistency
• Build the highest resilience apps with multi-Region strong consistency
• DynamoDB transactions