Examkin

Question

Difficulty: MediumHigh-Performing Database Solutions

A gaming company is developing a multiplayer online game and needs to design the database layer for its player profile and game state service. The service must handle a peak workload of 45,00045,000 write operations per second for state updates and 90,00090,000 read operations per second for profile queries. Read requests for the most active players must have a sub-millisecond (microsecond) latency, while write operations must complete in less than 1010 milliseconds. The traffic is highly dynamic and spikes during game events. Which database configuration should a solutions architect recommend to achieve the required performance?

  1. A
    Configure Amazon DynamoDB with Amazon DynamoDB Accelerator (DAX) to cache read requests, and use a formatted Timestamp (YYYY-MM-DD-HH) as the partition key to ensure players are ordered by join date.
  2. B
    Configure Amazon RDS for MySQL in a Multi-AZ deployment, configure the application to send write operations to the primary DB instance, and configure the application to use a Read Replica as the primary failover target for write operations if the primary DB instance fails.
  3. Configure Amazon DynamoDB with Amazon DynamoDB Accelerator (DAX) to cache read requests, and use a unique UUIDv4 PlayerID as the partition key to distribute write operations evenly across partitions.Answer
  4. D
    Configure Amazon DynamoDB in Provisioned Capacity Mode, using a partition key of GameRegion (with 33 distinct values) to group player profiles by geographic area.

Answer

Configure Amazon DynamoDB with Amazon DynamoDB Accelerator (DAX) to cache read requests, and use a unique UUIDv4 PlayerID as the partition key to distribute write operations evenly across partitions.
The configuration using Amazon DynamoDB with DynamoDB Accelerator (DAX) and a unique UUIDv4 PlayerID partition key is correct because DynamoDB naturally scales to meet high-throughput workloads, and DAX provides microsecond latency for hot read keys. A high-cardinality partition key like PlayerID (UUIDv4) distributes write traffic evenly across DynamoDB partitions, preventing performance bottlenecks and write throttling.

Step-by-Step Solution

1
Analyze the database requirements for read/write volume, latency, and access patterns.
The database must support 45,00045,000 writes/sec (millisecond latency) and 90,00090,000 reads/sec (microsecond latency). Traffic is highly dynamic and spiky.
This identifies the scale and performance targets to narrow down candidate database services.
2
Evaluate database services and cache mechanisms suitable for microsecond read latency.
Amazon DynamoDB with DynamoDB Accelerator (DAX) satisfies both the high write throughput and the microsecond read latency requirement for cached player profiles.
Relational options like Amazon RDS or Aurora do not natively support microsecond latencies without external caching, and DynamoDB is highly optimized for scale.
3
Design the partition key structure to handle 45,00045,000 writes/sec without throttling.
A high-cardinality partition key like a UUIDv4 PlayerID distributes writes uniformly across partitions, preventing partition hot-spotting.
DynamoDB partitions have a physical limit of 1,0001,000 write capacity units (WCU) per partition, so keys must be distributed evenly to avoid hot partitions.

Key Concept

To design high-performing database solutions, select partition keys with high cardinality (such as unique UUIDs) to distribute read and write traffic evenly across DynamoDB partitions, preventing hot spots. Use DynamoDB Accelerator (DAX) to provide microsecond read latency for frequently accessed items.
Estimated Time:2m 0s
Rate this question

Topics

High-Performing Database Solutions

More questions from this topic