DynamoDB最终一致性读取与强一致性读取：选型场景及权衡点咨询

Hey there! Let’s dig into DynamoDB’s two read modes—strongly consistent vs. eventually consistent—and break down when to pick which. I’ve spent countless hours optimizing DynamoDB workloads, so here’s the practical, no-fluff breakdown you need:

1. First, the Core Definitions #

Strongly Consistent Reads #

• What it does: Every read returns the absolute latest data that’s been successfully written and synced across all DynamoDB replicas. If you write a value and immediately read it, you’ll get that new value—no exceptions.
• The tradeoffs:
  • Higher latency: It waits for all replicas to sync before responding, so expect slower response times compared to eventually consistent reads.
  • Double the cost: Each strongly consistent read consumes 2 Read Capacity Units (RCUs), while eventually consistent only uses 1.
  • Slightly lower availability: If any replica is down, a strongly consistent read might fail, since it needs confirmation from all copies.

Eventually Consistent Reads #

• What it does: Reads might return stale data (from before your last write) initially, but DynamoDB will sync all replicas within a few seconds—after that, reads will get the latest value. This is DynamoDB’s default read mode.
• The perks:
  • Lower latency: It pulls data from the nearest available replica, so responses are faster.
  • Half the cost: Only 1 RCU per read, which adds up to huge savings at scale.
  • Higher availability: As long as at least one replica is up, you’ll get a response.

2. How to Choose? Ask These Questions #

Do you need absolute real-time data? #

• Go with strongly consistent reads if:
  • You’re dealing with financial transactions (e.g., checking a user’s balance right after a transfer—stale data could cause errors).
  • Your app relies on immediate state updates (e.g., a game where a player needs to see their new item right after purchasing it).
  • A subsequent action depends on the latest write (e.g., verifying an order was created successfully before processing payment).
• Stick with eventually consistent reads if:
  • You’re displaying non-critical content (e.g., blog posts, product descriptions—stale data for a few seconds won’t break anything).
  • You’re running analytics or batch queries (e.g., daily sales reports—delays don’t impact accuracy here).
  • Data freshness isn’t a make-or-break factor (e.g., user profile stats that update every few seconds).

Is cost a concern? #

If your app has high read throughput, eventually consistent reads cut your read costs in half. For example, 1 million daily reads would cost 1 million RCUs with eventually consistent, vs. 2 million RCUs with strongly consistent—this is a massive difference for large-scale apps. Prioritize eventually consistent if freshness isn’t critical.

Do you need maximum performance or availability? #

• Strongly consistent reads have ~2-3x higher latency (based on real-world testing), so if your API needs sub-100ms response times, eventually consistent is the way to go.
• In multi-AZ deployments, strongly consistent reads require all AZs to sync—if one AZ goes down, your read might fail. Eventually consistent reads can fall back to other AZs, making them more resilient.

3. Pro Tip for Edge Cases #

If you’re unsure, start with eventually consistent reads (the default) and only use strongly consistent reads for specific critical operations. For example, in an e-commerce app:

• Use eventually consistent reads for browsing product listings.
• Switch to strongly consistent reads when checking if a product is in stock right before a user completes a purchase.

You can even add a fallback: do an eventually consistent read first, and if the data doesn’t match what you expect (e.g., a stock count that seems off), trigger a strongly consistent read to confirm. This balances cost and correctness.

内容的提问来源于stack exchange，提问作者Mahbubur Rahman Manik