Question

Difficulty: MediumPerformance and Scalability Optimization

A retail platform is launching a high-profile limited-edition sneaker release. Traffic is projected to jump instantly from 800800 requests per second to over 120,000120,000 requests per second within 60 seconds of the launch. The platform architecture consists of an Application Load Balancer (ALB) routing traffic to an Auto Scaling group of Amazon EC2 instances. The database tier is an Amazon RDS for PostgreSQL Multi-AZ DB instance. The primary performance bottleneck during the launch is retrieving product availability status. Which configuration should the Solutions Architect implement to scale the system and maintain low latency during the launch?

  1. Submit a request to AWS Support to pre-warm the Application Load Balancer to the expected throughput, and implement Amazon ElastiCache for Redis to cache and serve the product availability queries.Answer
  2. B
    Configure the Application Load Balancer with target tracking scaling policies to handle the traffic surge, and deploy Amazon RDS Read Replicas to offload product availability queries from the primary DB instance.
  3. C
    Submit a request to AWS Support to pre-warm the Application Load Balancer to the expected throughput, and configure the application to direct product availability read queries to the RDS standby DB instance in the secondary Availability Zone.
  4. D
    Submit a request to AWS Support to pre-warm the Application Load Balancer to the expected throughput, and deploy an Amazon ElastiCache for Memcached cluster with Multi-AZ replication enabled to cache product availability queries.

Answer

Request AWS Support to pre-warm the Application Load Balancer to the expected capacity, and cache product availability queries using Amazon ElastiCache for Redis.
The correct answer combines requesting ELB pre-warming from AWS Support with deploying Amazon ElastiCache for Redis. Pre-warming is required because standard ALB scaling cannot keep up with an instantaneous jump from 800800 to 120,000120,000 requests per second. ElastiCache for Redis successfully offloads the product availability queries from the RDS DB instance, providing high availability through Multi-AZ replication and sub-millisecond query response times.

Step-by-Step Solution

1
Evaluate the load balancer scaling requirements for flash traffic.
The traffic scales from 800800 to over 120,000120,000 requests per second in 60 seconds. This sudden volume requires ELB pre-warming because the default scaling rate of an Application Load Balancer cannot keep up with this rate of acceleration.
To prevent HTTP 502/504 gateways errors caused by the load balancer's inability to scale fast enough to meet instant demand.
2
Determine the optimal database read scaling and caching approach.
Amazon RDS standby instances cannot serve read traffic. While RDS Read Replicas can scale reads, ElastiCache for Redis is better suited to handle the highly repetitive queries for product availability at this extreme scale with sub-millisecond latencies.
To offload high-volume read traffic from the primary database engine and optimize response times.
3
Validate replication requirements for the caching layer.
ElastiCache for Redis supports Multi-AZ replication, ensuring high availability during the critical launch event, whereas ElastiCache for Memcached does not.
To ensure resiliency and scalability under high load.

Key Concept

Handling sudden flash traffic surges requires pre-warming the load balancer and offloading read traffic from the primary database using an appropriate caching layer like Amazon ElastiCache for Redis.
Rate this question