Question

Difficulty: MediumPerformance and Scalability Optimization

A company is launching a ticket booking platform that expects an instantaneous surge of 150,000150,000 concurrent users within a 33-minute window when a major event is announced. The application is hosted on Amazon ECS tasks behind an Application Load Balancer. The database tier uses an Amazon Aurora MySQL DB cluster. The initial user activity is heavily read-intensive, with users repeatedly checking ticket availability.

Which architectural design will provide the most performant and scalable solution to handle this traffic spike while minimizing latency?

  1. Implement Amazon ElastiCache for Redis to cache ticket availability status. Enable Aurora Auto Scaling for the read replicas to handle any backend read traffic. Submit a support ticket to AWS to pre-warm the Application Load Balancer before the ticket sale starts.Answer
  2. B
    Implement Amazon ElastiCache for Redis to cache ticket availability status. Enable Aurora Auto Scaling for the read replicas to handle any backend read traffic. Rely on the Application Load Balancer's native automatic scaling to dynamically handle the traffic surge.
  3. C
    Route read queries directly to the Amazon Aurora MySQL standby instance in the Multi-AZ deployment. Submit a support ticket to AWS to pre-warm the Application Load Balancer before the ticket sale starts.
  4. D
    Deploy an Amazon RDS MySQL DB instance with a Multi-AZ standby configuration. Direct read traffic to the standby DB instance during the sale, and rely on the Application Load Balancer's native automatic scaling.

Answer

Implement Amazon ElastiCache for Redis to cache ticket availability status, enable Aurora Auto Scaling for the read replicas to handle residual backend read traffic, and submit a support ticket to AWS to pre-warm the Application Load Balancer prior to the sale.
The correct answer combines Application Load Balancer pre-warming to handle the instant network surge, ElastiCache for Redis to cache repetitive database reads, and Aurora Auto Scaling for replicas to handle database read scaling. This meets the performance and scalability requirements of a flash traffic scenario.

Step-by-Step Solution

1
Address the immediate network ingestion layer capacity.
Requesting ALB pre-warming ensures that the load balancer is provisioned with sufficient capacity before the surge of 150,000150,000 users arrives.
Standard ALB auto-scaling reacts to traffic increases and takes time to scale out, resulting in dropped requests during sudden spikes.
2
Address the high-frequency query load on the database.
Caching the ticket availability queries in Amazon ElastiCache for Redis offloads the database tier.
Repeated read queries for the same availability data can be served with sub-millisecond latency from memory, preserving database resources.
3
Provide horizontal scale for database cache misses.
Enable Aurora Auto Scaling to dynamically provision additional Aurora Replicas based on CPU or connection metrics.
This scales database read capacity horizontally to handle any traffic that bypasses the cache.

Key Concept

Handling sudden, massive traffic spikes requires pre-provisioning capacity at the entry point (ALB pre-warming), caching repeating read queries using a fast caching layer (ElastiCache), and scaling the database horizontally using dedicated read replicas rather than passive standby instances.
Estimated Time:2m 0s
Rate this question