Soru

Zorluk: OrtaPerformance and Scalability Optimization

An online multiplayer gaming platform is launching a weekly synchronized global tournament. Every Sunday at 18:00 UTC, the platform experiences an instant traffic spike, growing from a baseline of 2,0002,000 active connections to over 90,00090,000 active players initiating matchmaking requests within 6060 seconds. The backend architecture consists of an Application Load Balancer (ALB), an Amazon ECS cluster running on AWS Fargate, and an Amazon DynamoDB table that stores player session states. During initial testing of the tournament start, players experienced high latency, and a significant number of matchmaking requests resulted in HTTP 503503 Service Unavailable errors. Monitoring indicates that the ECS tasks scale out, but the bottlenecks occur at the entry point and during database write operations due to the sudden nature of the surge. Which two actions should a solutions architect take to optimize the performance and scalability of the platform for the tournament? (Select TWO.)

  1. Submit a support ticket to AWS to pre-warm the Application Load Balancer to the expected throughput of 90,00090,000 concurrent player requests.Cevap
  2. Configure scheduled scaling actions for the DynamoDB table to scale up the provisioned write capacity units (WCUs) before the tournament begins, and scale them down afterward.Cevap
  3. C
    Rely on the default automatic scaling behavior of the Application Load Balancer to dynamically provision additional capacity as the tournament traffic arrives.
  4. D
    Deploy Amazon RDS Multi-AZ standby instances in parallel with the DynamoDB table to dynamically scale read and write traffic during the tournament peak.
  5. E
    Deploy Amazon ElastiCache for Memcached to cache player session states and configure multi-AZ replication to ensure session persistence across Availability Zones.

Cevap

The solutions architect should submit a support ticket to AWS to pre-warm the Application Load Balancer, and configure scheduled scaling actions for the DynamoDB table to scale up the provisioned write capacity units before the tournament begins.
The correct approach involves pre-warming the Application Load Balancer to handle the sudden, massive spike of 90,00090,000 concurrent matchmaking requests, and using scheduled scaling on the DynamoDB table to proactively provision sufficient write capacity before the tournament begins. This combination ensures that neither the traffic entry point nor the persistent storage layer becomes a bottleneck during the instant surge.

Adım Adım Çözüm

1
Analyze the traffic profile and entry-point constraints.
The platform experiences an instantaneous surge from 2,0002,000 to 90,00090,000 active players within 6060 seconds, which exceeds the rate at which an Application Load Balancer can automatically scale without dropping connections.
Requesting AWS to pre-warm the ALB to the anticipated load guarantees that the load balancer has sufficient capacity provisioned immediately at the start of the tournament.
2
Analyze the database scaling constraints.
DynamoDB's standard auto-scaling mechanism relies on target tracking policies, which require a few minutes of sustained traffic before triggering scale-up events, resulting in write throttling during the first few minutes of the tournament.
Proactively scheduling scaling actions to provision sufficient capacity before the tournament begins ensures that the database is fully ready to handle the immediate burst in write requests.
3
Evaluate and eliminate incorrect architectures.
Using RDS Multi-AZ standbys for read/write scaling is incorrect because standbys do not serve traffic. Using Memcached for replication and persistence is incorrect because Memcached is a simple key-value store without support for replication or persistence features.
This step validates that the chosen options are performant, architecturally sound, and aligned with AWS best practices.

Anahtar Kavram

Handling instantaneous flash traffic spikes requires proactive pre-warming of load balancers and scheduled scaling of database capacity to prevent scaling delays and throttling.
Bu soruyu puanla