Understanding Read Capacity Units (RCU) and Write Capacity Units (WCU) in Amazon DynamoDB

Amazon DynamoDB uses RCU and WCU in “provisioned capacity mode” to manage throughput for your database. RCUs determine the ability to handle read requests per second, while WCUs manage write requests. Both are tied to the size of the items being read or written.

Before that, lets go through Consistency models first as it is crucial needed to understand the RCU and WCU.

Strongly Consistent Reads

A strongly consistent read always returns the latest data written to the table. This ensures that if an update is made to the database, any subsequent read reflects that update immediately.

Key Features:

• Consistency: Always returns the latest data.
• RCU Consumption: Each “read request” consumes 1 RCU per 4 KB of data.
• Latency: Slightly higher latency compared to eventually consistent reads.

Use Case:

• Banking or financial systems where the latest balance or transaction must be fetched.
• Real-time leaderboards or dashboards that require up-to-date information.

Eventually Consistent Reads

An eventually consistent read might not return the latest data immediately. DynamoDB aims for consistency within 1 second, but during this time, a read might return stale data.

Key Features:

• Performance: Better performance and lower latency.
• RCU Efficiency: Consumes half the RCUs compared to a strongly consistent read.
• Consistency Guarantee: Suitable for non-critical reads where slightly stale data is acceptable.

Use Case:

• Applications like e-commerce product catalogs or blog posts, where minor delays in reflecting updates are tolerable.
• Analytics systems that process approximate real-time data.

So, Use Strongly Consistent Reads when:

• Your application requires real-time and accurate data.
• Missing or stale data can cause significant issues.

And, Use Eventually Consistent Reads when:

• You prioritize cost savings and performance over strict consistency.
• Applications can tolerate slight delays in data synchronization.

This flexibility allows DynamoDB to optimize performance and cost based on your application’s requirements.

Transactional Reads

Transactional reads in DynamoDB allow you to read multiple items atomically, ensuring strongly consistent reads across all items involved. This guarantees that the data returned is accurate and synchronized, making it ideal for workflows requiring coordinated reads of interrelated data, such as retrieving customer orders and inventory details together.

Key Features:

• Guarantees ACID (Atomicity, Consistency, Isolation, Durability) compliance.
• Performs multiple reads within a transaction as a single, consistent operation.
• RCU Consumption: Consumes double the RCUs compared to standard strongly consistent reads.

Use Case:

• Financial applications needing consistent multi-item reads (e.g., fetching account balances and recent transactions).
• Coordinated retrieval of interdependent data such as orders and customer details.

Transactional Writes

Transactional writes enable multiple items to be updated atomically, ensuring that all changes either succeed together or fail. This is critical for scenarios like updating inventory and customer payments in the same operation.

Key Features:

• Ensures that all writes succeed or none are applied, maintaining data consistency.
• Supports complex workflows requiring multi-item atomic operations.
• WCU Consumption: Consumes double the WCUs compared to standard writes.

Use Case:

• Inventory updates involving stock reduction and order creation.
• Payment processing systems where customer accounts and transaction records are updated together.

We are now ready to understand Read Capacity Units (RCU) and Write Capacity Units (WCU) in DynamoDB.

Read Capacity Units (RCU)

One RCU allows:

• 1 strongly consistent read per second for an item up to 4 KB.
• 2 eventually consistent reads per second for an item up to 4 KB.

If an item’s size exceeds 4 KB, the RCUs scale linearly based on the item size.

RCU Calculation Example

Let’s consider item size: 10 KB and number of reads: 10 per second.

Strongly Consistent Reads:

• Each 10 KB item requires 3 RCUs because it is split into 3 chunks of 4 KB (4 KB + 4 KB + 2 KB).
• Total needed = 10 reads × 3 = 30 RCU.

Eventually Consistent Reads:

• Each 10 KB item still requires 3 RCUs, but since eventually consistent reads consume half the RCUs:
• Total needed = (10 reads × 3) / 2 =15 RCU.

Transactional Reads:

• Each 10 KB item requires 3 RCUs, but transactional reads consume double the RCUs of strongly consistent reads:
• Total needed = 10 reads × 3 × 2 = 60 RCU.

Write Capacity Units (WCU)

One WCU allows:

• 1 write per second for an item up to 1 KB.

If an item exceeds 1 KB, WCUs scale linearly.

WCU Calculation Example
Let’s consider item size: 10 KB and number of standard writes: 10 per second.

• Each 10 KB item requires 10 WCUs because it is split into 10 chunks of 1 KB each.
• Total needed = 10 writes × 10 = 100 WCU.

While with Transactional Writes:

• Each 10 KB item requires 10 WCUs, but transactional writes consume double the WCUs of standard writes:
• Total needed = 10 writes × 10 × 2 = 200 WCU.

Combined Use Case

Suppose you have the following requirements:

• Read 100 items per second (each item is 6 KB).
• Eventually Consistent Reads.
• Write 50 items per second (each item is 2 KB).

Calculate RCUs

• Each 6 KB item requires 2 RCUs (split into 2 chunks of 4 KB each).
• Total reads = 100 per second.
• Total RCUs: 100 × 2 = 200.
  Since reads are eventually consistent, divide by 2:
  200 / 2 = 100 RCU.

Calculate WCUs

• Each 2 KB item requires 2 WCUs (split into 2 chunks of 1 KB each).
• Total writes = 50 per second.
• Total WCUs: 50 × 2 = 100 WCU.

Total Provisioned Capacity:

• RCUs: 100.
• WCUs: 100.

Optimization Opportunities for RCU/WCU

1. Batch Operations:
   Combine multiple items into a single read or write request using batch APIs. This reduces the number of individual operations and optimizes capacity unit usage.
2. Reduce Item Size:
   Minimize the size of items stored in the table. Compress data where possible, split infrequently used attributes into separate tables, or store large objects in S3 and reference them in DynamoDB.
3. Caching with DAX (DynamoDB Accelerator):
   Use DAX to cache frequently accessed items in memory. This significantly reduces RCU consumption for read-heavy workloads.
4. Leverage On-Demand Mode:
   For unpredictable traffic patterns, use the on-demand mode to automatically scale capacity and avoid overprovisioning RCUs and WCUs.
5. Indexing (GSI and LSI):
   Use GSIs and LSIs judiciously for additional query flexibility. Remember, indexes consume RCUs/WCUs independently, so create them only if necessary. More details in The Good, the Bad, and the Ugly of GSI and LSI in Amazon DynamoDB.
6. Avoid Overfetching Data:
   Query or scan only the attributes you need using ProjectionExpression or similar methods. Fetching unnecessary attributes increases item size and RCU/WCU usage.
7. Optimize Query Patterns:
   Design your table schema to leverage partition keys and sort keys effectively. Avoid full table scans, which are RCU-intensive.
8. Time-to-Live (TTL):
   Use TTL to automatically delete expired items, reducing storage and WCU costs associated with manual cleanup.

As a summary, Amazon DynamoDB uses Read Capacity Units (RCU) and Write Capacity Units (WCU) in provisioned capacity mode to manage database throughput. Strongly consistent reads ensure real-time accuracy but consume more RCUs, while eventually consistent reads are faster and cost-efficient, suitable for non-critical use cases. Transactional reads and writes guarantee ACID compliance (Atomicity, Consistency, Isolation, Durability) for critical operations but consume double the RCUs/WCUs compared to non-transactional operations. RCUs scale based on item size (4 KB chunks) and read type, while WCUs scale with item size (1 KB chunks). Optimizations include batching, reducing item sizes, caching with DAX, leveraging on-demand mode, indexing wisely, avoiding overfetching, optimizing queries, and using Time-to-Live (TTL) for expired data. These strategies improve cost-efficiency and performance

💡 Please let me know in the comments if you agree with me or if I missed something.

Thank you for your time 😊