Question

Difficulty: HardPerformance and Scalability Optimization

A media company is launching a global mobile voting application for a live televised talent show. The show expects up to 55 million users to submit votes concurrently within a televised 55-minute window. The votes must be ingested, validated, and aggregated in real-time, with results displayed on screen. The ingestion tier must handle an immediate jump from zero traffic to over 100,000100,000 write requests per second. The backend database requires single-digit millisecond latency for write operations and must scale horizontally to handle the peak write volume. Which of the following architectures provides the most performant, scalable, and operationally efficient solution to meet these requirements?

  1. A
    Deploy an Application Load Balancer (ALB) to route traffic to an Auto Scaling Group of Amazon EC2 instances. Configure target tracking scaling on the ALB requests per target metric, and configure the EC2 instances to write votes to an Amazon RDS Multi-AZ PostgreSQL database.
  2. B
    Deploy an Application Load Balancer (ALB) to route traffic to Amazon Elastic Container Service (Amazon ECS) on AWS Fargate. Configure target tracking scaling with a short cooldown period of 1010 seconds on the ECS service to handle rapid scale-out. Write vote data to an Amazon DynamoDB table with on-demand capacity mode.
  3. Deploy a Network Load Balancer (NLB) to route traffic to an Amazon Elastic Container Service (Amazon ECS) cluster on AWS Fargate. Pre-warm the ECS tasks by configuring scheduled scaling to launch the required number of tasks before the voting window opens. Write vote data to an Amazon DynamoDB table configured with provisioned capacity, pre-provisioned to 100,000100,000 Write Capacity Units (WCUs), using a partition key with high cardinality such as a combination of ContestantID and a random shard number.Answer
  4. D
    Deploy an Application Load Balancer (ALB) and submit a support ticket to AWS to pre-warm the ALB to handle the expected traffic. Route traffic to an Amazon ECS service on AWS Fargate. Write vote data to an Amazon Aurora MySQL database, and enable Aurora Auto Scaling for the reader endpoint to scale the database to handle the write volume.

Answer

Deploy a Network Load Balancer (NLB) to route traffic to an Amazon Elastic Container Service (Amazon ECS) cluster on AWS Fargate. Pre-warm the ECS tasks by configuring scheduled scaling to launch the required number of tasks before the voting window opens. Write vote data to an Amazon DynamoDB table configured with provisioned capacity, pre-provisioned to 100,000100,000 Write Capacity Units (WCUs), using a partition key with high cardinality such as a combination of ContestantID and a random shard number.
The correct architecture uses a Network Load Balancer (NLB) which natively handles sudden, massive spikes in traffic without the need for pre-warming. In addition, scheduling ECS task scaling before the event ensures that the compute tier is ready to process requests immediately. Pre-provisioning DynamoDB Write Capacity Units (WCUs) ensures that the database has the required throughput, and utilizing write sharding (ContestantID + random shard) avoids hot partitions by distributing write operations across multiple physical partitions.

Step-by-Step Solution

1
Analyze ingestion tier load patterns and select the load balancer.
An instantaneous jump from zero to over 100,000100,000 requests per second requires a load balancer that handles sudden spikes without pre-warming. A Network Load Balancer (NLB) is selected.
An Application Load Balancer (ALB) requires pre-warming to scale to massive volumes instantly, and without it, it will drop requests during sudden spikes. NLB can scale to millions of requests per second immediately.
2
Select and configure the compute tier scaling strategy.
Pre-warm the compute tier by configuring scheduled scaling on the ECS service to launch the required tasks before the televised voting window starts.
Target tracking or step scaling policies are reactive and take time to bootstrap new tasks, which would result in request failures during the initial minutes of the event.
3
Select and configure the database tier for high-throughput writes.
Use Amazon DynamoDB with provisioned capacity pre-scaled to 100,000100,000 WCUs and a sharded partition key design.
DynamoDB handles single-digit millisecond write latencies. Pre-provisioning WCUs avoids throttling that occurs when on-demand capacity attempts to scale up instantly from zero, and partition sharding prevents hot partition issues.

Key Concept

Handling sudden flash traffic spikes by combining NLB (which scales instantly without pre-warming), scheduled compute scaling, and pre-provisioned DynamoDB tables with partition key sharding.
Estimated Time:3m 0s
Rate this question