A gaming leaderboard uses DynamoDB with 85% repeated reads of player ranks, p99 latency spiked to 18 ms during tournaments, and developers cannot add cache invalidation code due to a freeze. Which data caching strategy optimizes DynamoDB performance without application rewrites?

The scenario is dominated by 85% repeated reads with p99 at 18 ms and a freeze prohibiting invalidation code, which calls for a DynamoDB-native read cache, and placing DAX in front of the table fits because it serves GetItem and Query hits from memory in microseconds while write-through keeps ranks coherent automatically without application changes. The ElastiCache for Redis design is a proven leaderboard cache for sub-millisecond hits, yet as a concept it requires application-side lookup logic to load, read, and expire keys, so it breaks the no-rewrite condition despite matching latency goals. The global tables design is proven for multi-Region scale and fault tolerance by replicating data and spreading read traffic, yet as a concept replication is not memory caching and cannot deliver microsecond hits for repeated keys in one tournament Region, so it misses the repeated-read fact. The CloudFront edge design is proven for offloading repeated API reads with low edge latency, yet as a concept it caches HTTP responses rather than providing DynamoDB-integrated write-through, so rank updates would remain stale without edge invalidation that the freeze forbids. As an exam caveat, eliminate any attractive latency or throughput improvement that does not explicitly preserve automatic coherence with zero code changes. As a practical check, validate DAX cache hit rate, microsecond p99, and reduced DynamoDB consumed reads during a tournament replay before promotion.