Elite Four Production Review

MREC is the default: writes replicate asynchronously and concurrent changes use last-writer-wins reconciliation. Transactions are atomic in the originating Region, not across replicas.

MRSC synchronously replicates writes and supports strongly consistent reads across replicas. It currently does not support TTL or transaction APIs. GSIs remain eventually consistent. These tradeoffs matter more than simply enabling a global table.

The lab chooses MREC to retain TTL and regional transactions. Its productionPlan is a teaching checklist, not an AWS SDK input object.

On-demand capacity is a strong default for unknown or spiky traffic, while provisioned capacity can be economical for predictable loads. Both modes still depend on well-distributed partition keys. A hot battle feed may need deterministic write sharding such as BATTLE#2026-07-17#03 and a fan-out read across shards.

DynamoDB read cost depends on item size and consistency. Prefer eventual reads where the application tolerates slight lag; use strong reads deliberately. GSI and Streams reads are eventually consistent, so workflows must tolerate propagation delay.

• Use DynamoDB Streams for change-data capture. Each change appears exactly once in the stream (ordered per item), but consumers such as Lambda retry failed batches, so processing must be idempotent.
• Global tables offer MREC (eventual replication with last-writer-wins conflict resolution) and MRSC (strong reads across replicas when requested). Choose explicitly and check supported Regions before deployment.
• Enable point-in-time recovery with a 1–35 day recovery period; restores create a new table. Regularly test restoration and application cutover.
• Keep objects approaching DynamoDB's 400 KB item limit in S3 and store only metadata and an object key in DynamoDB.

DynamoDB always encrypts data at rest; choose the KMS key type (AWS owned, AWS managed, or customer managed) your compliance needs, use TLS in transit, and grant least-privilege IAM permissions scoped to the required tables, indexes, actions, and leading keys where possible.

• Monitor throttled requests, system errors, latency, consumed capacity, and account/table limits.
• Load-test real access patterns and item sizes; averages hide the hot keys that fail first.
• Document retry policy with exponential backoff and jitter, idempotency strategy, cost budget, and regional failure behavior.
• Use DAX only after measuring a read-heavy, eventually consistent cacheable workload; it does not repair a poor key design.