Examkin

Question

Difficulty: HardPerformance and Scalability Optimization

A logistics company is designing a new package tracking system to support a major global expansion. The system must ingest package location scans from sorting facilities, averaging 120,000120,000 write requests per second with burst peaks up to 250,000250,000 writes per second. Customers globally will query the API for real-time tracking updates, generating up to 600,000600,000 read requests per second. The read queries must return tracking data with sub-10 millisecond10\text{ millisecond} latency. The architecture must be highly scalable, performant, and minimize operational overhead. Which of the following database and tiering designs meets these requirements most efficiently?

  1. A
    Route write requests through an Application Load Balancer (ALB) to an Amazon ECS cluster running on AWS Fargate. Write the tracking data to an Amazon RDS for PostgreSQL database. To handle the read queries, configure the application to route read traffic to the RDS Multi-AZ standby instance in the secondary Availability Zone, and configure RDS Auto Scaling to add more standby nodes as query volume increases.
  2. B
    Expose an HTTPS endpoint using an Application Load Balancer (ALB) that invokes AWS Lambda functions directly to write package scans to an Amazon DynamoDB table. Leave Lambda reserved concurrency unconfigured to allow the functions to scale freely. To handle the customer read queries, deploy an Amazon ElastiCache for Memcached cluster to cache the tracking details.
  3. Route incoming write requests through a Network Load Balancer (NLB) to an Amazon Kinesis Data Stream. Process the stream using AWS Lambda functions with provisioned concurrency configured to prevent scaling latency, and write the tracking data to an Amazon DynamoDB table. Deploy an Amazon DynamoDB Accelerator (DAX) cluster to serve the high-volume tracking read queries with sub-millisecond latency.Answer
  4. D
    Route write traffic through a Network Load Balancer (NLB) to Amazon EC2 instances in an Auto Scaling Group. Write the tracking data to an Amazon DynamoDB table. To handle customer read queries, deploy an Amazon ElastiCache for Memcached cluster to cache tracking status, and configure multi-AZ replication to ensure the cache remains highly available and synchronized across regions.

Answer

Route incoming write requests through a Network Load Balancer (NLB) to an Amazon Kinesis Data Stream. Process the stream using AWS Lambda functions with provisioned concurrency configured to prevent scaling latency, and write the tracking data to an Amazon DynamoDB table. Deploy an Amazon DynamoDB Accelerator (DAX) cluster to serve the high-volume tracking read queries with sub-millisecond latency.
The correct architecture uses a Network Load Balancer (NLB) to scale instantly without the pre-warming limits associated with ALBs. The writes are buffered in Amazon Kinesis Data Streams, which manages high-throughput ingestion. Lambda functions process the stream using provisioned concurrency to eliminate scaling latency. Amazon DynamoDB stores the tracking records, and DynamoDB Accelerator (DAX) caches the reads to easily handle the 600,000600,000 read queries per second with sub-millisecond latency, preventing database read exhaustion.

Step-by-Step Solution

1
Analyze write ingestion layer scalability.
The ingestion tier must scale to handle spikes of up to 250,000250,000 write requests per second. A Network Load Balancer (NLB) handles millions of requests per second with ultra-low latency and scales instantly, making it superior to an Application Load Balancer (ALB) for raw TCP/UDP ingestion without pre-warming. Buffering through Amazon Kinesis Data Streams protects downstream systems from database saturation.
Decoupling ingestion via a stream buffer prevents write dropouts and ensures smooth scaling during high traffic spikes.
2
Evaluate database engine performance.
Amazon DynamoDB handles horizontal scale seamlessly, accommodating hundreds of thousands of write requests per second without the replication lag, storage allocation, or connection management limitations of traditional relational databases like RDS PostgreSQL.
DynamoDB scales partitions automatically to handle high-throughput workloads with predictable, single-digit millisecond write latencies.
3
Determine read caching and latency reduction strategies.
To handle 600,000600,000 read queries per second under 10 milliseconds10\text{ milliseconds}, a caching layer in front of the database is required. Amazon DynamoDB Accelerator (DAX) is an in-memory cache that integrates natively with DynamoDB API operations. It reduces read latency to microseconds and significantly lowers the required read capacity units (RCUs) on the underlying table.
DAX simplifies cache management and delivers sub-millisecond read latency without requiring complex application caching code.

Key Concept

Ingestion buffering with Kinesis, serverless scaling with Lambda, and read caching with DynamoDB Accelerator (DAX) for high-performance and low-latency workloads.
Estimated Time:3m 0s
Rate this question

Topics

Performance and Scalability Optimization

More questions from this topic