Elite Four Production Review

Scale and consistency

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 asBATTLE#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.

Events, regions, and recovery

• Use DynamoDB Streams for change-data capture; consumers must be idempotent because records can be delivered more than once.
• Global Tables provide multi-Region, multi-active replication with conflict behavior that the application must understand and test.
• Enable point-in-time recovery, define retention needs, and regularly prove that restore procedures work.
• Keep objects approaching DynamoDB's 400 KB item limit in S3 and store only metadata and an object key in DynamoDB.

Security and operations

Encrypt at rest with an appropriate KMS key strategy, 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.