Examkin

Question

Difficulty: Very hardHigh-Performing Database Solutions

A media company is launching a live interactive voting platform for a popular television tournament. During a 10-minute voting window, the platform must ingest a sudden burst of up to 100,000100,000 votes per second. Each vote payload consists of a unique `VoteID`, the `ContestantID` (representing one of 5 finalists), and a `Timestamp`. The platform requires microsecond-level latency to query real-time leaderboard statistics by `ContestantID` for display on the live broadcast. Which database architecture should a solutions architect recommend to support this scale and performance while preventing write throttling?

  1. A
    Amazon RDS for PostgreSQL Multi-AZ DB cluster with three read replicas, routing all write operations to the read replicas to distribute the transactional load, and utilizing Amazon ElastiCache for Redis to cache contestant vote totals.
  2. B
    Amazon DynamoDB in provisioned capacity mode with Auto Scaling enabled, using `ContestantID` as the partition key and `Timestamp` as the sort key, with a global secondary index (GSI) on `VoteID` to distribute the write operations.
  3. Amazon DynamoDB in on-demand capacity mode, using a composite primary key consisting of a partition key of `ContestantID` appended with a random integer suffix and a sort key of `Timestamp`, with Amazon DynamoDB Accelerator (DAX) deployed to cache read queries.Answer
  4. D
    Amazon DynamoDB in provisioned capacity mode, using `VoteID` as the partition key and a local secondary index (LSI) on `ContestantID` to query leaderboard statistics, with Amazon ElastiCache for Memcached caching the query results.

Answer

Amazon DynamoDB in on-demand capacity mode, using a composite primary key consisting of a partition key of ContestantID appended with a random integer suffix and a sort key of Timestamp, with Amazon DynamoDB Accelerator (DAX) deployed to cache read queries.
The correct architecture uses Amazon DynamoDB in on-demand capacity mode to handle the sudden, massive voting spikes that auto scaling with provisioned capacity cannot adapt to fast enough. Because there are only 5 contestants, using ContestantID directly as the partition key would limit writes to only 5 partitions. A single DynamoDB partition supports a maximum of 1,0001,000 write capacity units (WCUs) per second, so 100,000100,000 writes per second would cause massive throttling. Appending a random integer suffix (e.g., ContestantID_1 through ContestantID_100) shards the partition key, distributing the writes across many physical partitions to handle the throughput. Amazon DynamoDB Accelerator (DAX) is natively integrated with DynamoDB to provide microsecond-level read latency for the leaderboard queries.

Step-by-Step Solution

1
Analyze the capacity requirement for a sudden 10-minute window spike.
Identify that provisioned capacity mode with auto scaling is insufficient because auto scaling reacts slowly and cannot scale up instantaneously to handle a spike from zero to 100,000100,000 requests per second. On-demand capacity mode is required.
On-demand mode instantly accommodates rapid traffic spikes without needing to pre-provision capacity.
2
Analyze the database partition key structure to avoid hot partitions.
Recognize that with only 5 contestants, using ContestantID directly as the partition key concentrates all writes onto 5 physical partitions. Because DynamoDB limits write throughput to 1,0001,000 write capacity units (WCUs) per second per physical partition, the total write limit would be capped at 5,0005,000 WCUs/sec, causing massive throttling at 100,000100,000 writes/sec. Suffixing the ContestantID with a random integer (e.g., ContestantID_1 to ContestantID_100) distributes the writes across 500 physical partitions.
Write sharding (partition key suffixing) is the standard technique to distribute write traffic for low-cardinality keys.
3
Select the caching solution to meet microsecond read latency.
Amazon DynamoDB Accelerator (DAX) is selected because it is a fully managed, highly available, in-memory cache for DynamoDB that delivers microsecond response times for read operations.
DAX integrates natively with DynamoDB, eliminating the need to write custom caching logic.
4
Evaluate and discard alternative database architectures.
Discard the Amazon RDS option because RDS read replicas are read-only and cannot accept write traffic, and discard the LSI option due to the 10 GB item collection limit.
Correct database write patterns and resource limits must be respected.

Key Concept

DynamoDB partition key sharding (write-sharding) and capacity mode selection for highly spiky, high-throughput database workloads.
Rate this question

Topics

High-Performing Database Solutions

More questions from this topic