Question

Difficulty: HardPerformance and Scalability Optimization

A global advertising technology company is designing a real-time bidding and analytics platform. The platform must process over 22 million bid requests per second with sub-10 millisecond latency. The bidding system is stateless and deployed on Amazon ECS on AWS Fargate. Behind the bidding service, a read-heavy database stores user profiles (10 TB10\text{ TB}) and a write-heavy ingestion pipeline receives transaction logs. During scheduled high-profile sporting events, incoming request traffic spikes instantly from a baseline of 100,000100,000 requests per second to 2,000,0002,000,000 requests per second in less than one minute. Which two of the following architectural strategies should the solutions architect implement to optimize performance and scalability for these spikes? (Select TWO.)

  1. Deploy a Network Load Balancer (NLB) at the ingress tier to handle the instantaneous traffic surge without pre-warming, and configure Amazon ECS scheduled scaling to scale out the bidding tasks before the events begin.Answer
  2. Use Amazon Aurora PostgreSQL for the user profiles database, deploy Aurora Replicas to scale read capacity horizontally, and configure Application Auto Scaling to dynamically adjust the replica count based on CPU utilization.Answer
  3. C
    Rely on the default Application Load Balancer (ALB) auto-scaling to absorb the flash traffic spike, and configure target tracking scaling policies on CPU utilization for both the ALB and the ECS Fargate tasks.
  4. D
    Utilize a Multi-AZ Amazon RDS PostgreSQL deployment for the user profiles, and configure the bidding application to distribute read queries between the primary instance and the standby replica to double read capacity.
  5. E
    Deploy an Amazon ElastiCache for Memcached cluster to cache the user profiles, enabling Multi-AZ with automatic failover to guarantee cache persistence and replica synchronization.

Answer

Deploying a Network Load Balancer (NLB) at the ingress tier combined with scheduled ECS scaling, and using Amazon Aurora PostgreSQL with auto-scaling Aurora Replicas.
The correct strategy combines Network Load Balancers (NLBs) with Amazon ECS scheduled scaling to handle the immediate ingress and compute load, and uses Amazon Aurora Replicas to scale database reads. NLBs handle rapid, massive traffic surges natively without requiring pre-warming. Scheduled scaling ensures that the ECS tasks are scaled out in advance of the known event start time. For the database tier, Amazon Aurora Replicas scale read operations horizontally and support Application Auto Scaling to adjust capacity based on CPU utilization.

Step-by-Step Solution

1
Analyze the ingestion tier requirements under sudden flash traffic.
Identify that the ingress tier must scale from 100,000100,000 to 2,000,0002,000,000 requests per second in less than a minute. Standard ALBs require manual pre-warming for such instant spikes, whereas NLBs can handle sudden millions of requests natively.
Ensures the ingress layer does not drop connections or experience high latency during the initial moments of the spike.
2
Evaluate compute scaling mechanisms for rapid spikes.
Determine that target tracking and step scaling policies are reactive and take minutes to spin up tasks, which is too slow for sub-minute spikes. Scheduled scaling is required to scale out Fargate tasks proactively.
Ensures that compute capacity matches the incoming traffic volume before the load hits the system.
3
Evaluate database read scaling strategy.
Determine that the database must scale horizontally for reads. Since RDS Multi-AZ standby instances cannot serve reads, Amazon Aurora Replicas with Application Auto Scaling should be used to dynamically scale read operations.
Provides elastic read capacity to handle lookup traffic without overloading the database writer node.

Key Concept

Handling instantaneous, extreme load spikes requires proactive compute scaling, load balancers capable of handling rapid traffic shifts without pre-warming, and horizontal read scaling on the database tier.
Estimated Time:2m 30s
Rate this question