DynamoDB Accelerator (DAX)

Correct Answer: Use DynamoDB with a Global Secondary Index

A Global Secondary Index (GSI) lets you project the leaderboard into an alternate access pattern optimized for querying the top N by score without scanning the entire table. Model the GSI with a fixed partition key (for example, a constant like "global" or a gameId/region key) and the sort key as the player score. Then issue a Query with ScanIndexForward set to false and a Limit (e.g., 100) to return the highest scores efficiently at scale. This design supports frequent score updates and high read throughput. A Local Secondary Index is unsuitable because it requires sharing the base table's partition key, which prevents efficient global top-N queries and does not scale if all items share a single partition. Using DynamoDB without an index forces table scans, which are inefficient and expensive. Storing data in S3 and computing periodically does not meet low-latency, up-to-date leaderboard requirements. If ultra-low read latency under heavy load is needed, you may add a cache later (e.g., DAX), but the correct foundational solution is a GSI.

Correct Answer: Use DynamoDB Accelerator (DAX)

DynamoDB Accelerator (DAX) is a fully managed, in-memory cache specifically built for DynamoDB that can reduce read latency from milliseconds to microseconds for hot items. It integrates with the DynamoDB SDK as a drop-in cache, handling cache population, write-through updates, and item invalidation without requiring custom application logic. Increasing provisioned throughput primarily prevents throttling but does not drastically reduce per-request latency. DynamoDB does not offer traditional read replicas, and using ElastiCache would require building and maintaining custom caching and invalidation logic, making it more complex and error-prone compared to DAX.

Correct Answer: Utilize DAX for micro-caching

DynamoDB Accelerator (DAX) is a fully managed, in-memory cache specifically for DynamoDB that delivers microsecond read latency for repeated point-reads. It integrates as a drop-in client with minimal code changes, reduces read load on the table, and is ideal when the workload is read-heavy, repeatedly accesses the same items, and can tolerate eventually consistent reads without using DynamoDB transactions. Increasing provisioned throughput does not reliably reduce latency unless the table is throttling. Offloading to ElastiCache requires building and maintaining custom caching and invalidation logic and is less seamless for DynamoDB. Migrating to RDS is a major redesign and unnecessary for this use case.