Examkin

Question

Difficulty: HardPerformance and Scalability Optimization

A global smart-grid utility company is deploying a system to monitor 8,000,0008,000,000 smart meters. At exactly 00:00 UTC each day, every meter uploads a 2 KB2\text{ KB} JSON status payload via HTTPS to a telemetry endpoint. The system must process this data and store it in an Amazon Aurora PostgreSQL database for daily reporting. The telemetry ingestion endpoint experiences a sudden traffic spike, surging from a baseline of under 1010 requests per second (RPS) to over 150,000150,000 RPS within 3030 seconds. Which architecture provides the most performant and scalable design to ingest and process this data without dropping requests?

  1. Deploy an Application Load Balancer (ALB) that routes incoming requests to an Amazon ECS service running on AWS Fargate. Have the ECS tasks ingest the payloads directly into an Amazon Kinesis Data Stream. Configure a separate ECS service to consume data from Kinesis and perform batched writes to the Aurora PostgreSQL database. Contact AWS Support to pre-warm the ALB with the anticipated traffic profile.Answer
  2. B
    Deploy an Application Load Balancer (ALB) that routes incoming requests to an Amazon ECS service running on AWS Fargate. Rely on the ALB's built-in automatic scaling to adapt to the daily traffic spike, and configure Auto Scaling for the ECS service based on CPU utilization. To handle the database write pressure, configure Aurora Auto Scaling to dynamically launch Aurora Replicas during the ingestion window.
  3. C
    Deploy an Application Load Balancer (ALB) that routes incoming requests to an Amazon ECS service running on AWS Fargate. Configure the ECS tasks to write payloads directly to the Aurora PostgreSQL database. Set up Amazon ElastiCache for Memcached to cache database queries and reduce database lock contention. Configure the ALB with an aggressive target tracking scaling policy based on target response time.
  4. D
    Deploy an Application Load Balancer (ALB) that routes incoming requests to an Amazon ECS service running on AWS Fargate. Contact AWS Support to pre-warm the ALB. Configure the ECS tasks to write payloads directly to the Aurora PostgreSQL database. To scale the write throughput, configure Aurora Global Database write forwarding and distribute the telemetry data writes across multiple secondary AWS Regions.

Answer

Deploy an Application Load Balancer (ALB) that routes incoming requests to an Amazon ECS service running on AWS Fargate. Have the ECS tasks ingest the payloads directly into an Amazon Kinesis Data Stream. Configure a separate ECS service to consume data from Kinesis and perform batched writes to the Aurora PostgreSQL database. Contact AWS Support to pre-warm the ALB with the anticipated traffic profile.
The correct solution addresses the network layer bottlenecks by pre-warming the Application Load Balancer (ALB) through AWS Support, ensuring it can handle the sudden 150,000150,000 RPS load. It also addresses the database layer bottleneck by introducing Amazon Kinesis Data Streams to buffer the telemetry payloads, allowing the backend tasks to perform efficient batch inserts into Aurora PostgreSQL instead of direct, high-frequency, single-record writes.

Step-by-Step Solution

1
Evaluate the traffic spike characteristics and the capacity of the Application Load Balancer (ALB).
An instantaneous traffic surge from 1010 to 150,000150,000 RPS within 3030 seconds exceeds the rate at which an ALB can reactively scale, requiring pre-warming by AWS Support.
Standard ALB scaling requires a few minutes to scale out to support massive surges. Pre-warming configures the load balancer with enough capacity to handle the peak load immediately.
2
Analyze the database write requirements and options for buffering.
Directly writing 150,000150,000 payloads per second to Aurora PostgreSQL will overwhelm the database with write locks and connection limits.
Using Amazon Kinesis Data Streams decouples telemetry ingestion from database writes. This allows consumer tasks to read from the stream and batch the writes to Aurora, which is significantly more efficient than individual writes.
3
Review the scaling behavior of database replicas and global write forwarding features.
Aurora Replicas and Aurora Global Database write forwarding do not scale write throughput horizontally on the primary database instance.
Aurora Replicas only serve read queries, and write forwarding merely redirects writes to the single primary instance, keeping it as the bottleneck.

Key Concept

Handling flash traffic spikes requires pre-warming the load balancing layer and decoupling the database writes from the ingestion API using a message queue or data stream to buffer the load.
Rate this question

Topics

Performance and Scalability Optimization

More questions from this topic