Question

Difficulty: MediumPerformance and Scalability Optimization

An online multiplayer gaming platform is preparing for a global tournament broadcast. During the broadcast, the concurrent user session count is expected to surge instantly from a steady state of 1,2001,200 requests per second to over 75,00075,000 requests per second within a 33-minute window. The platform's frontend is served by an Application Load Balancer (ALB), and the session metadata is stored in an Amazon Aurora PostgreSQL database. The Solutions Architect needs to optimize the architecture to ensure that the platform can scale to handle the spike without latency degradation or dropped connection requests, while maintaining a caching layer that supports replication. Which TWO actions should the Solutions Architect take to design a performant and scalable solution? (Select TWO.)

  1. Contact AWS Support to pre-warm the Application Load Balancer (ALB) prior to the tournament broadcast.Answer
  2. Deploy an Amazon ElastiCache for Redis cluster with Multi-AZ enabled to cache the session metadata.Answer
  3. C
    Rely on the default auto-scaling behavior of the Application Load Balancer (ALB) to handle the traffic surge.
  4. D
    Enable Amazon Aurora Auto Scaling and direct read requests to the database standby instance in the secondary Availability Zone.
  5. E
    Deploy an Amazon ElastiCache for Memcached cluster to cache the session metadata, enabling multi-AZ replication.

Answer

Contact AWS Support to pre-warm the Application Load Balancer (ALB) and deploy an Amazon ElastiCache for Redis cluster with Multi-AZ.
Pre-warming the Application Load Balancer (ALB) prepares it to handle the sudden, massive traffic spike from the start, as the standard dynamic scaling of an ALB is too slow for instantaneous spikes of this magnitude and will cause dropped connections. Amazon ElastiCache for Redis with Multi-AZ enabled is the correct caching solution because it supports replication, failover, and high availability, which offloads read traffic from the primary database.

Step-by-Step Solution

1
Analyze the load profile and ALB scaling behavior.
Identify that the traffic spike from 1,2001,200 to 75,00075,000 requests per second in 33 minutes is too rapid for automatic ALB scaling, necessitating pre-warming.
Standard ALB auto-scaling is reactive and cannot scale fast enough to meet instant, high-magnitude traffic spikes.
2
Select the appropriate caching strategy for highly available leaderboard data.
Choose ElastiCache for Redis with Multi-AZ over Memcached.
ElastiCache for Redis supports data replication and multi-AZ failover, which are necessary for high availability, unlike Memcached.
3
Evaluate database scaling options.
Avoid directing read traffic to a Multi-AZ standby since it cannot serve traffic.
Standard RDS Multi-AZ standbys do not accept connection endpoints for read queries.

Key Concept

Pre-warming load balancers and utilizing replication-capable caching layers to handle instant scale and offload databases.
Rate this question