Question

Difficulty: HardPerformance and Scalability Optimization

A global gaming publisher is launching a real-time multiplayer matchmaking platform. The session coordination system must handle a baseline load of 5,0005,000 requests per second, which is expected to spike to 750,000750,000 requests per second within 33 minutes during the launch event. The matchmaking state is highly transient, read-and-write intensive, and requires sub-millisecond latency. The architecture must guarantee high availability across multiple Availability Zones. Which architecture represents the most performant, scalable, and operationally efficient design to meet these requirements?

  1. An Application Load Balancer (ALB) that has been pre-warmed via an AWS Support request, routing traffic to Amazon ECS tasks running on AWS Fargate. Matchmaking state is stored in an Amazon ElastiCache for Redis cluster running in a Multi-AZ configuration with automatic failover enabled.Answer
  2. B
    An Application Load Balancer (ALB) routing traffic to an Amazon ECS service running on AWS Fargate with aggressive target tracking scaling policies. Matchmaking state is stored in an Amazon ElastiCache for Redis cluster running in a Multi-AZ configuration. The ALB scales automatically using default capacity scaling.
  3. C
    An Application Load Balancer (ALB) that has been pre-warmed via an AWS Support request, routing traffic to Amazon ECS tasks running on AWS Fargate. Matchmaking state is stored in a multi-node Amazon ElastiCache for Memcached cluster to leverage multi-threaded performance and cross-Availability Zone replication.
  4. D
    An Application Load Balancer (ALB) that has been pre-warmed via an AWS Support request, routing traffic to Amazon ECS tasks running on AWS Fargate. Matchmaking state is stored in an Amazon RDS for PostgreSQL database running in a Multi-AZ deployment, where read queries are routed to the standby replica to distribute the read load.

Answer

The architecture using a pre-warmed Application Load Balancer, Amazon ECS on AWS Fargate, and Amazon ElastiCache for Redis in a Multi-AZ configuration.
The correct answer combines an AWS Support pre-warmed Application Load Balancer to absorb the immediate traffic surge with Amazon ECS on Fargate for containerized computation. It utilizes Amazon ElastiCache for Redis in a Multi-AZ configuration to support high-throughput, low-latency transient state storage with automated replication and failover.

Step-by-Step Solution

1
Evaluate the routing tier scalability under sudden spike conditions.
The platform requires handling a massive jump from 5,0005,000 to 750,000750,000 requests per second in 33 minutes. Standard Application Load Balancers scale gradually. A flash spike of this magnitude requires requesting ELB pre-warming from AWS Support to prevent connection timeouts and packet loss.
ELB pre-warming pre-allocates the underlying capacity necessary to handle the instantaneous load.
2
Determine the optimal database technology for highly transient, sub-millisecond matchmaking state.
Matchmaking state is highly transient and requires sub-millisecond latencies. In-memory databases are the correct choice. Amazon ElastiCache for Redis provides the required latency and data structure support.
Relational databases like PostgreSQL introduce unnecessary transactional overhead and cannot reliably meet sub-millisecond read/write latency requirements at this scale.
3
Ensure database high availability and replication characteristics match requirements.
Amazon ElastiCache for Redis supports Multi-AZ replication with automatic failover, satisfying the high availability requirement. Amazon ElastiCache for Memcached only supports horizontal scaling through partitioning without built-in replication or automatic failover.
Multi-AZ replication ensures durability and availability of active session keys in the event of an Availability Zone outage.

Key Concept

Handling sudden high-volume traffic spikes on ALB and selecting appropriate high-performance, replicated in-memory storage.
Rate this question