Examkin

Question

Difficulty: Very hardPerformance and Scalability Optimization

A global sports streaming platform is launching a new interactive live-betting feature for an upcoming championship event. The platform expects an instantaneous surge in traffic, growing from a baseline of 1,0001,000 requests per second to over 600,000600,000 concurrent write-heavy API requests per second within a 22-minute window whenever a critical game event occurs. The backend architecture must process these bets with sub-10 millisecond database write latencies and support real-time read queries for live odds updates, which scale dynamically based on active viewers. The current design draft proposes using an Application Load Balancer (ALB) backed by an Amazon Auto Scaling group of Amazon EC2 instances, with Amazon Aurora PostgreSQL as the primary database.

Which architecture optimization strategy will meet these performance and scalability requirements with the least operational overhead?

  1. A
    Configure the Application Load Balancer (ALB) to rely on its default automatic scaling behaviors to absorb the traffic burst. Deploy an Amazon Aurora PostgreSQL DB cluster, configure Aurora Serverless v2 to automatically scale the writer node, and implement Aurora Auto Scaling to dynamically add read replicas to handle live odds query spikes.
  2. B
    Contact AWS Support to pre-warm the Application Load Balancer (ALB) for the target transaction volume. To manage database scaling, deploy a primary Amazon RDS for PostgreSQL DB instance with a Multi-AZ standby replica, and configure the application to route read queries for live odds directly to the standby replica.
  3. Contact AWS Support to pre-warm the Application Load Balancer (ALB) for the anticipated traffic volume. Migrate the ingestion tier to Amazon DynamoDB with pre-split partitions and provisioned capacity to handle the write burst, and deploy Amazon DynamoDB Accelerator (DAX) to deliver sub-millisecond read latency for live odds.Answer
  4. D
    Utilize Amazon Route 53 latency routing to distribute the traffic across multiple Application Load Balancers (ALBs) without pre-warming. Deploy Amazon Aurora PostgreSQL and configure an Amazon ElastiCache for Memcached cluster to act as a database cache, relying on the application to dynamically write updates to Memcached and database standby instances simultaneously.

Answer

Contact AWS Support to pre-warm the Application Load Balancer (ALB) for the anticipated traffic volume. Migrate the ingestion tier to Amazon DynamoDB with pre-split partitions and provisioned capacity to handle the write burst, and deploy Amazon DynamoDB Accelerator (DAX) to deliver sub-millisecond read latency for live odds.
The correct architecture addresses both the load balancing and database scalability bottlenecks. Pre-warming the ALB ensures that AWS pre-configures the load balancer's capacity to handle the 600,000 requests per second immediately. Amazon DynamoDB scales horizontally, and with pre-split partitions and provisioned capacity, it can easily handle the 600,000 writes per second. Amazon DynamoDB Accelerator (DAX) handles the read-heavy live odds queries with sub-millisecond latencies, offloading the database.

Step-by-Step Solution

1
Analyze ingress scaling capabilities.
Identify that a sudden jump from 1,0001,000 to 600,000600,000 requests per second in 2 minutes is too fast for standard ALB scaling. AWS Support pre-warming is required to provision sufficient capacity in advance.
Default ALB scaling uses a gradual DNS and IP provisioning process that cannot react to instantaneous multi-hundred-thousand request spikes, causing HTTP 503 errors and dropped requests.
2
Evaluate database write scaling requirements.
Determine that relational databases (like Aurora PostgreSQL or RDS PostgreSQL) with a single writer cannot scale to support 600,000 concurrent writes/sec. Migrate the database tier to Amazon DynamoDB.
DynamoDB is a non-relational database designed for horizontal scalability. By pre-splitting partitions and provisioning the required write capacity units, it can handle virtually unlimited writes/sec.
3
Determine the optimal read cache strategy.
Select Amazon DynamoDB Accelerator (DAX) to cache the live odds read queries.
DAX is a fully managed, highly available in-memory cache for DynamoDB that delivers microsecond response times for read-heavy workloads at scale.

Key Concept

Handling extreme flash traffic spikes requires pre-warming the load balancing tier and utilizing horizontally scalable, non-relational database architectures with caching.
Estimated Time:3m 0s
Rate this question

Topics

Performance and Scalability Optimization

More questions from this topic