Examkin

Question

Difficulty: HardPerformance and Scalability Optimization

A mobile gaming company is launching a multiplayer game with a weekly competitive event. The event ends every Sunday at 20:00 UTC, at which point the leaderboard is frozen, rewards are calculated, and players immediately log in to claim their rewards and view the final rankings. The peak traffic is projected to jump instantly from a baseline of 2,0002,000 requests per second (RPS) to 350,000350,000 RPS within 30 seconds30\text{ seconds}. The leaderboard and session state must be persistent, highly available across multiple Availability Zones, and support sub-millisecond read/write latency. The backend consists of a microservices architecture hosted on Amazon Elastic Container Service (Amazon ECS) on AWS Fargate, fronted by an Application Load Balancer (ALB). The primary database is an Amazon Aurora MySQL cluster. Which design should a solutions architect recommend to handle this sudden surge in load while maintaining optimal performance?

  1. Request AWS Support to pre-warm the Application Load Balancer (ALB) to handle the expected 350,000350,000 RPS. Configure Amazon ECS Auto Scaling using scheduled scaling policies to scale out Fargate tasks ahead of the event. Use Amazon ElastiCache for Redis to cache session and leaderboard state with replication across Availability Zones, and configure Aurora Auto Scaling to add Aurora Replicas to the cluster based on CPU utilization.Answer
  2. B
    Rely on the Application Load Balancer's automatic scaling capacity to dynamically scale as traffic increases. Configure Amazon ECS Auto Scaling based on target tracking policies for CPU utilization. Use Amazon ElastiCache for Redis to store session state, and add an Amazon Aurora Multi-AZ standby instance to handle the increased read traffic.
  3. C
    Request AWS Support to pre-warm the Application Load Balancer (ALB) to handle the expected 350,000350,000 RPS. Configure Amazon ECS Auto Scaling using scheduled scaling policies to scale out Fargate tasks ahead of the event. Use Amazon ElastiCache for Memcached to store session and leaderboard state across multiple nodes, and configure Aurora Auto Scaling to scale out read replicas based on CPU utilization.
  4. D
    Rely on the Application Load Balancer's automatic scaling capacity to handle the surge. Configure Amazon ECS Auto Scaling using target tracking policies based on ALB request count per target. Use Amazon ElastiCache for Redis to store session state, and configure the Amazon Aurora cluster to scale out reads by adding Aurora Replicas based on CPU utilization.

Answer

Request AWS Support to pre-warm the Application Load Balancer (ALB), scale out Fargate tasks using scheduled scaling, utilize Amazon ElastiCache for Redis to handle session and leaderboard state with Multi-AZ replication, and use Aurora Auto Scaling with Aurora Replicas to scale read capacity.
The correct design addresses the scalability limits at every layer of the architecture. Pre-warming the ALB ensures the network routing layer is ready for the massive initial wave of traffic. Scheduled scaling for ECS Fargate ensures the application containers are bootstrapped and running before the rush begins. Using ElastiCache for Redis provides the required sub-millisecond latencies for session and leaderboard state while ensuring high availability through Multi-AZ replication. Finally, using Aurora Auto Scaling ensures database read capacity scales horizontally with replica instances.

Step-by-Step Solution

1
Address the immediate network ingress spike by requesting ALB pre-warming from AWS Support.
The ALB is configured with sufficient capacity beforehand to prevent connection drops when the traffic spikes to 350,000350,000 RPS.
Default ALB scaling processes can take several minutes to respond to sudden traffic increases, which is too slow for a 3030-second flash event.
2
Configure scheduled scaling for the ECS Fargate tasks to execute shortly before 20:00 UTC.
Compute instances are provisioned and warm, ready to immediately process the incoming player traffic.
Target tracking scaling is reactive and cannot spin up containers fast enough to prevent CPU exhaustion during the initial seconds of the spike.
3
Deploy Amazon ElastiCache for Redis to cache leaderboards and session state.
Sub-millisecond latency is achieved, and session data is preserved across Availability Zones via replication.
Unlike Memcached, Redis supports replication and data persistence, satisfying the high availability and state preservation requirements.
4
Configure Aurora Auto Scaling to dynamically provision read replicas.
The database read load is offloaded to horizontal replicas, maintaining primary database performance.
Aurora Replicas are required to scale read traffic. Multi-AZ standby instances cannot serve traffic and only function as failover targets.

Key Concept

Handling rapid, scheduled flash traffic spikes requires proactive provisioning (pre-warming, scheduled scaling) at the load balancing and compute tiers, combined with horizontal read replica scaling and high-availability caching using Redis.
Estimated Time:3m 0s
Rate this question

Topics

Performance and Scalability Optimization

More questions from this topic