Examkin

Question

Difficulty: MediumPerformance and Scalability Optimization

A regional public transit authority is launching a mobile ticketing application to support commuters during a city-wide cultural festival. The authority expects an immediate traffic burst where active user sessions will surge from 500500 to over 80,00080,000 within a 55-minute window. The backend application runs on Amazon EC2 instances inside an Auto Scaling group behind an Application Load Balancer (ALB), with transactional data stored in a Multi-AZ Amazon RDS for PostgreSQL database. High-frequency queries retrieve transit schedule data which changes daily. Which architecture optimization strategy should a Solutions Architect recommend to handle this sudden traffic spike while maintaining low-latency read operations?

  1. Configure Amazon ElastiCache for Redis to cache the daily transit schedule data, and submit a support ticket to AWS to pre-warm the Application Load Balancer before the festival begins.Answer
  2. B
    Configure Amazon ElastiCache for Redis to cache the daily transit schedule data, and rely on the Application Load Balancer's automatic scaling to handle the traffic increase as active users connect.
  3. C
    Configure the application to route read queries for transit schedules to the secondary standby instance of the Multi-AZ Amazon RDS PostgreSQL database, and submit a support ticket to AWS to pre-warm the Application Load Balancer.
  4. D
    Deploy Amazon ElastiCache for Memcached with multi-AZ replication to cache the schedule data, and rely on the Application Load Balancer's automatic scaling to adjust to the traffic volume.

Answer

Configure Amazon ElastiCache for Redis to cache the daily transit schedule data, and submit a support ticket to AWS to pre-warm the Application Load Balancer before the festival begins.
The correct answer combines pre-warming the Application Load Balancer to prepare for the massive, rapid surge in connections, and caching the static transit schedules in ElastiCache for Redis. This strategy ensures the load balancer has sufficient capacity from the start and offloads read queries from the primary transactional database, maintaining low-latency response times.

Step-by-Step Solution

1
Analyze the scaling characteristics of the entry point (Application Load Balancer) during an extreme, sudden surge of traffic.
Identify that the ALB needs to scale from a baseline supporting 500 sessions to 80,000 sessions within 5 minutes. Since the default scaling rate of ALBs cannot accommodate this extreme rate of increase, a pre-warming request must be submitted to AWS Support.
This prevents HTTP 503 errors and connection timeouts at the load balancer layer during the initial minutes of the festival spike.
2
Evaluate options for offloading read-heavy, daily changing transit schedule queries from the transactional database.
Determine that caching the schedules using Amazon ElastiCache for Redis is the most performant and low-latency mechanism to handle the high-frequency queries.
This offloads read traffic from the RDS database, protecting the primary database instance's CPU and memory resources for write-heavy ticketing transactions.
3
Verify database replication and high availability constraints for read traffic.
Confirm that RDS PostgreSQL Multi-AZ standby instances cannot be read from directly, and rule out any options attempting to route queries to the standby.
Only Read Replicas (not the Multi-AZ standby instance) support read traffic in RDS PostgreSQL.

Key Concept

Caching static read data with ElastiCache for Redis and pre-warming Application Load Balancers for immediate, extreme traffic spikes.
Estimated Time:1m 30s
Rate this question

Topics

Performance and Scalability Optimization

More questions from this topic