Examkin

Question

Difficulty: Very hardHigh-Performing Database Solutions

A gaming company is launching a multiplayer online game that stores player state updates in an Amazon DynamoDB table. The application performs up to 150,000150,000 write operations per second during peak hours. The partition key is currently designed as `GameSessionDate` (formatted as `YYYY-MM-DD`) and the sort key is `PlayerID`. During load testing, the database experiences write throttling even though the provisioned write capacity units (WCUs) are scaled far beyond the requirements. Additionally, the application requires sub-millisecond latency for game session read queries. Which database architecture modification should the solutions architect implement to resolve the performance bottleneck and meet the latency requirements?

  1. A
    Modify the partition key to use a monotonically increasing timestamp to ensure chronological order, and configure Amazon ElastiCache for Memcached to cache read queries.
  2. B
    Migrate the player state to Amazon RDS for PostgreSQL with Read Replicas, configuring the application to failover write operations to the Read Replicas during high-throughput events.
  3. Redesign the table schema to append a randomized shard suffix to the `GameSessionDate` partition key, and deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache read requests.Answer
  4. D
    Retain the current key schema but switch the DynamoDB capacity mode to Provisioned Mode, configuring the sort key `PlayerID` with a monotonically increasing sequence number to distribute writes across partitions.

Answer

Redesign the table schema to append a randomized shard suffix to the `GameSessionDate` partition key, and deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache read requests.
The correct answer resolves the write throttling issue by implementing write sharding on the partition key. Appending a randomized suffix to the date partition key distributes the 150,000150,000 write operations per second across multiple physical partitions. Additionally, deploying DynamoDB Accelerator (DAX) satisfies the requirement for sub-millisecond read latency by providing an in-memory cache directly integrated with the database.

Step-by-Step Solution

1
Analyze the current DynamoDB partition design and identify the bottleneck.
The partition key `GameSessionDate` only changes daily, causing all concurrent writes for a single day to hit the same partition.
DynamoDB distributes data across partitions based on the partition key. A single partition has performance limits (1,0001,000 WCUs and 3,0003,000 RCUs), leading to throttling when writes exceed these limits.
2
Introduce write sharding to distribute writes.
Appending a random shard suffix (e.g., 11 to NN) to the partition key distributes the write workload across multiple partitions.
This design ensures that write requests are spread evenly, preventing hot partitions and resolving the throttling issue.
3
Select the appropriate caching mechanism for sub-millisecond read queries.
Deploying a DynamoDB Accelerator (DAX) cluster provides in-memory caching directly integrated with DynamoDB.
DAX delivers microsecond response times for read queries and operates transparently without requiring application-level caching logic changes.

Key Concept

Partition key design, write sharding, and write/read performance scaling in Amazon DynamoDB.
Estimated Time:3m 0s
Rate this question

Topics

High-Performing Database Solutions

More questions from this topic