Question

Difficulty: HardPerformance and Scalability Optimization

A retail company is launching a new flash sale platform that expects an immediate and massive surge in traffic, going from 00 to 500,000500,000 concurrent requests per second within less than 2 minutes. The architecture consists of a public-facing Application Load Balancer (ALB), an Amazon ECS cluster on AWS Fargate for the web tier, and an Amazon Aurora PostgreSQL database cluster for the transactional backend. The application profile is highly read-intensive during the sale. Which two options should a Solutions Architect recommend to optimize the performance and scalability of the platform under this sudden load?

  1. Request AWS Support to pre-warm the Application Load Balancer (ALB) to handle the anticipated surge of 500,000500,000 requests per second, and configure scheduled scaling for the Amazon ECS tasks to scale out prior to the start of the event.Answer
  2. B
    Rely on the Application Load Balancer (ALB) to scale dynamically using its default built-in capacity, and use Target Tracking scaling policies to scale out the Amazon ECS tasks once CPU utilization exceeds 70%70\%.
  3. Add Aurora Replicas to the Amazon Aurora PostgreSQL database cluster, configure Aurora Auto Scaling to scale the reader nodes dynamically, and configure the application to direct read queries to the Aurora reader endpoint.Answer
  4. D
    Configure the database using a standard Amazon RDS Multi-AZ deployment and configure the application to send read-heavy queries to the standby instance in the secondary Availability Zone to offload the primary writer.
  5. E
    Deploy Amazon ElastiCache for Memcached to cache query results, and configure Multi-AZ replication to ensure high availability and read-scaling of the cache nodes during the event.

Answer

Request AWS Support to pre-warm the Application Load Balancer (ALB) with scheduled scaling for the ECS tasks, and deploy Aurora Replicas using Aurora Auto Scaling with read queries directed to the reader endpoint.
To survive an instantaneous surge in traffic, the entry point must be pre-warmed to ensure AWS has pre-provisioned sufficient ALB capacity. Correspondingly, Scheduled Auto Scaling must be used to ensure the ECS tasks are ready before the traffic starts. Database read scalability must be solved by routing queries to the Aurora reader endpoint, which distributes connections among dynamically scaled Aurora Replicas.

Step-by-Step Solution

1
Analyze the load balancing tier scalability limits under instant flash traffic.
Identify that a sudden surge to 500,000500,000 requests per second in 2 minutes exceeds the default automatic scaling rate of an ALB.
Requesting ALB pre-warming from AWS Support is required to prevent packet loss, and scheduled scaling ensures ECS tasks are running before the spike occurs.
2
Evaluate the database tier capability for read-intensive workloads.
Determine that scaling database reads requires horizontal replicas and load-balanced reader connections.
Aurora PostgreSQL Replicas with Auto Scaling and the reader endpoint satisfy high-throughput read demands, whereas Multi-AZ standbys cannot serve read traffic.

Key Concept

Architectures facing sudden, massive flash traffic must pre-allocate capacity at the load balancing and compute layers (pre-warming and scheduled scaling) and leverage horizontal scaling replica architectures at the database tier.
Rate this question