Question

Difficulty: Very hardPerformance and Scalability Optimization

A global payment processing company is designing a real-time fraud detection platform. The system must ingest credit card transaction events from merchant terminals worldwide, processing a baseline of 200,000200,000 write requests per second. During promotional sales, traffic instantly surges to 3 million3\text{ million} write requests per second. The application must analyze each transaction against historical user profiles stored in a backend database with sub-1010-millisecond latency. High-volume read queries for these profiles must scale dynamically to handle concurrent validation checks. Which architecture meets these scalability and performance requirements while minimizing operational overhead?

  1. Deploy a Network Load Balancer (NLB) in front of an Amazon ECS Service on AWS Fargate. Store user profiles in an Amazon Aurora PostgreSQL DB cluster, directing write traffic to the primary writer endpoint and read queries to the cluster reader endpoint. Configure Aurora Auto Scaling to dynamically adjust the number of Aurora Replicas based on CPU utilization.Answer
  2. B
    Deploy an Application Load Balancer (ALB) in front of an Amazon ECS Service on AWS Fargate. Use Amazon RDS for PostgreSQL in a Multi-AZ deployment. Direct the application write traffic to the primary database instance and route the high-volume read queries to the Multi-AZ standby instance in the secondary Availability Zone.
  3. C
    Deploy an Application Load Balancer (ALB) to route traffic to an Amazon ECS Service on AWS Fargate. Store user profiles in an Amazon Aurora PostgreSQL DB cluster. Direct write traffic to the primary writer instance, and configure Aurora Auto Scaling to scale out the database instances. Rely on the ALB's default auto-scaling behavior to dynamically scale from the baseline to the peak flash traffic.
  4. D
    Deploy a Network Load Balancer (NLB) in front of an Amazon ECS Service on AWS Fargate. Store user profiles in a single-node Amazon RDS for PostgreSQL DB instance. Implement an Amazon ElastiCache for Memcached cluster to act as a write-through cache for the PostgreSQL database, configuring Memcached to replicate data across multiple Availability Zones to ensure high availability.

Answer

Deploy a Network Load Balancer (NLB) in front of an Amazon ECS Service on AWS Fargate. Store user profiles in an Amazon Aurora PostgreSQL DB cluster, directing write traffic to the primary writer endpoint and read queries to the cluster reader endpoint. Configure Aurora Auto Scaling to dynamically adjust the number of Aurora Replicas based on CPU utilization.
The architecture utilizing a Network Load Balancer (NLB) and Amazon Aurora PostgreSQL with reader endpoints and Auto Scaling provides the optimal solution. The NLB natively handles instantaneous, volatile spikes of millions of requests per second without requiring pre-warming. Amazon Aurora's cluster reader endpoint load balances read queries across dynamically scaled Aurora Replicas, which scaling policies can provision automatically in response to CPU load. This ensures the backend meets sub-1010-millisecond latency requirements under heavy write and read pressures.

Step-by-Step Solution

1
Analyze the ingestion scaling requirements to determine the appropriate load balancer tier.
Identify that the system must handle an instant traffic surge from 200,000200,000 to 3 million3\text{ million} write requests per second.
An Application Load Balancer (ALB) requires pre-warming to handle such rapid, massive spikes, and relying on its default auto-scaling will lead to dropped connections. A Network Load Balancer (NLB) is designed to scale to millions of requests per second instantly without pre-warming.
2
Evaluate the database tier for write performance and dynamic read scaling capabilities.
Select Amazon Aurora PostgreSQL over traditional RDS PostgreSQL.
Amazon Aurora supports up to 1515 Aurora Replicas that can be scaled dynamically using Auto Scaling policies to handle variable read loads, whereas RDS Multi-AZ standby instances are passive and cannot serve read queries.
3
Determine the proper configuration for routing database read and write queries.
Point write queries to the primary instance (writer endpoint) and read validation queries to the reader endpoint.
The reader endpoint automatically load balances connections across the active Aurora Replicas, enabling seamless horizontal scale-out of read queries under load to maintain sub-1010-millisecond latency.

Key Concept

Handling flash traffic spikes at the ingress layer using NLB, and scaling database reads horizontally using Aurora Auto Scaling and read replicas.
Estimated Time:3m 0s
Rate this question