A major ticketing platform is preparing for a global concert ticket launch. The platform e… — AWS Certified Solutions Architect - Professional

A major ticketing platform is preparing for a global concert ticket launch. The platform expects an instantaneous traffic spike, surging from a baseline of $2,000$ requests per second to $600,000$ requests per second within $3$ minutes (a $300\times$ increase). The current architecture consists of an Application Load Balancer (ALB) routing traffic to containerized microservices hosted on Amazon ECS using AWS Fargate. The microservices query an Amazon Aurora PostgreSQL database cluster for ticket inventory and real-time seat availability. The architecture must minimize latency, handle the massive flash traffic without dropping requests, and dynamically scale the read capacity of the database tier. Which of the following architectures meets these requirements with the highest performance and operational efficiency?

Submit a support ticket to AWS to pre-warm the Application Load Balancer to handle the expected peak of $600,000$ requests per second. Configure a scheduled scaling policy on the Amazon ECS service to scale out Fargate tasks ahead of the launch. Enable Aurora Auto Scaling for the Aurora PostgreSQL database cluster to dynamically add Aurora Replicas based on CPU utilization to handle the read query load.Answer
B
Rely on the Application Load Balancer's automatic scaling capability to scale up during the event. Configure target tracking scaling policies on the Amazon ECS Fargate service based on Average CPU Utilization. Enable Aurora Auto Scaling on the Aurora PostgreSQL database cluster to add reader instances as load increases.
C
Submit a support ticket to AWS to pre-warm the Application Load Balancer. Configure a scheduled scaling policy on the Amazon ECS service to scale out Fargate tasks. Migrate the database to Amazon RDS for PostgreSQL with a Multi-AZ deployment, and configure the application to route read queries to the standby database instance in the secondary Availability Zone to handle the read query load.
D
Submit a support ticket to AWS to pre-warm the Application Load Balancer. Configure a scheduled scaling policy on the Amazon ECS service to scale out Fargate tasks. Deploy an Amazon ElastiCache for Memcached cluster with Multi-AZ auto-failover enabled to cache database query results and serve read traffic.

Answer

Submit a support ticket to AWS to pre-warm the Application Load Balancer, configure a scheduled scaling policy on Amazon ECS to scale out Fargate tasks, and enable Aurora Auto Scaling for the Aurora PostgreSQL cluster.

The correct architecture combines pre-emptive scaling actions (ALB pre-warming and ECS scheduled scaling) to bypass the bootstrap latency of reactive scaling policies during an instantaneous flash crowd. For the database layer, it correctly leverages Aurora Replicas and Aurora Auto Scaling to distribute the read query load horizontally across multiple active endpoints.

Step-by-Step Solution

Address the entry point scaling limitation.

The Application Load Balancer is pre-warmed by AWS Support to handle the target throughput of

600,000

requests per second.

An ALB scales dynamically based on traffic, but a sudden

300\times

surge within

3

minutes exceeds the rate at which the ALB can spawn new controller nodes, leading to connection timeouts and dropped packets.

Pre-provision compute resources for the microservices.

ECS Fargate tasks are scaled out prior to the event using a scheduled scaling policy.

Fargate tasks require time to pull container images, bootstrap, and pass health checks. Relying on reactive target tracking during an instantaneous spike results in a severe compute deficit during the critical initial minutes of the launch.

Scale the database read capacity horizontally.

Aurora Auto Scaling is enabled to dynamically provision Aurora Replicas based on CPU utilization.

Aurora supports up to

15

reader replicas that share the same underlying storage volume with minimal replication lag (typically under

100\text{ ms}

), providing a highly performant and scalable read tier.

Key Concept

Handling extreme flash traffic spikes requires pre-warming load balancers, scheduled compute scaling, and horizontal read scaling using database replicas instead of passive disaster recovery instances.

Alternative Method

Instead of relying on relational read replicas, the architecture could incorporate Amazon DynamoDB with DynamoDB Accelerator (DAX) if the data model is migrated to a key-value store, enabling microsecond read latencies and seamless horizontal scaling for high-frequency reads.

Estimated Time:3m 0s

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Alternative Method

Topics

More questions from this topic