A gaming platform stores player leaderboard data in DynamoDB (managed NoSQL database, distributes data across internal partitions — each partition has its own throughput ceiling). The table uses game_id as the partition key and player_id as the sort key. The platform runs 15 active games. One game — game_id = "battle-royale" — accounts for 78% of all read traffic. It is the flagship title that launched 6 months ago and still dominates the player base.
The table is provisioned at 10,000 RCUs. CloudWatch (AWS monitoring service, reports consumed RCUs as a table-level aggregate across all partitions) shows average consumed RCUs at 4,300 — well under the provisioned capacity. But ThrottlingException errors are spiking on leaderboard reads for battle-royale during peak hours, and P99 read latency has climbed to 820 ms.
The on-call engineer opens a ticket to increase provisioned capacity to 20,000 RCUs. The support team approves the change. It goes live.
The throttling does not stop. CloudWatch still shows consumed RCUs well below the new limit.
You have 10,000 RCUs of headroom sitting idle and a table that is still throttling. What is actually happening?
A) Yes — doubling provisioned RCUs gives the table enough capacity headroom to absorb the battle-royale traffic spike
B) No — the table needs to migrate to DynamoDB on-demand capacity mode (no pre-provisioned capacity, adapts per-partition throughput dynamically), which removes per-partition limits entirely
C) No — battle-royale is a hot partition; per-partition throughput limits apply regardless of total table RCU provisioning; traffic concentrated on one partition key hits that partition’s ceiling even when the table has headroom
D) No — the issue is a missing GSI (Global Secondary Index — a secondary index for alternate access patterns) on game_id causing full partition scans on leaderboard reads
답글 남기기