Soru

Zorluk: OrtaPerformance and Scalability Optimization

A logistics company is designing a new real-time package delivery tracking system. During peak holiday seasons, query traffic for package status is expected to spike instantly from 2,0002,000 requests per second to 250,000250,000 requests per second. The system must also ingest 50,00050,000 GPS coordinate updates per second from delivery vehicles. The tracking status queries require a latency of less than 5 milliseconds5\text{ milliseconds}. Which architecture meets these performance and scalability requirements with the least operational overhead?

  1. Deploy a Network Load Balancer (NLB) to handle the GPS ingestion, routing to an Amazon Elastic Container Service (ECS) cluster. Store the package tracking status in Amazon ElastiCache for Redis with replication, and serve status queries from the Redis read replicas.Cevap
  2. B
    Deploy an Application Load Balancer (ALB) to handle the GPS ingestion, routing to an Amazon ECS cluster. Rely on default ALB auto-scaling to scale the load balancer during the peak traffic spike, and store the tracking status in Amazon DynamoDB with auto-scaling enabled.
  3. C
    Deploy a Network Load Balancer (NLB) to handle the GPS ingestion, routing to an Amazon ECS cluster. Store the tracking status in a Multi-AZ Amazon RDS for PostgreSQL database, and route all package status queries to the standby DB instance to handle the read query volume.
  4. D
    Deploy a Network Load Balancer (NLB) to handle the GPS ingestion, routing to an Amazon ECS cluster. Store the tracking status in Amazon ElastiCache for Memcached, and configure a replication group across multiple Availability Zones to scale the tracking status queries.

Cevap

Deploy a Network Load Balancer (NLB) to handle the GPS ingestion, routing to an Amazon Elastic Container Service (ECS) cluster. Store the package tracking status in Amazon ElastiCache for Redis with replication, and serve status queries from the Redis read replicas.
The correct architecture uses a Network Load Balancer (NLB), which is optimized for ultra-low latency and handles sudden, volatile traffic spikes of millions of requests per second without pre-warming. For storage, Amazon ElastiCache for Redis with replication is chosen because it easily meets the sub-5ms read latency requirement and supports replication groups, allowing reads to scale horizontally on replicas while the primary node handles the 50,00050,000 writes per second GPS ingestion rate.

Adım Adım Çözüm

1
Select the appropriate load balancer for volatile and sudden traffic spikes.
Choose a Network Load Balancer (NLB) because it can scale to millions of requests per second instantly without requiring pre-warming, unlike an Application Load Balancer (ALB).
The scenario describes a flash spike from 2,0002,000 to 250,000250,000 requests per second, which would overwhelm a standard ALB before it could auto-scale.
2
Select the database/caching tier that meets the sub-5ms read latency constraint and handles high write volumes.
Choose Amazon ElastiCache for Redis with replication.
Redis provides sub-millisecond latencies. By deploying a replication group, we can offload read queries to read replicas while reserving the primary node for the 50,00050,000 writes per second.
3
Evaluate the capabilities of alternative configurations against replication and scaling constraints.
Rule out Memcached (no replication support) and RDS Multi-AZ standby (cannot serve read traffic).
Memcached is multi-threaded but lacks replication, meaning it cannot scale reads via dedicated read replicas. An RDS standby database in a standard Multi-AZ configuration is strictly passive and cannot be queried.

Anahtar Kavram

Selecting load balancing and caching tiers capable of handling sudden, high-velocity traffic spikes and scaling read capacity horizontally.
Tahmini Süre:2m 0s
Bu soruyu puanla