Examkin

Question

Difficulty: Very hardImproving Database and Caching Efficiency

A ride-hailing company operates its dispatch system on AWS, tracking real-time driver coordinates and matching them with passengers. The platform currently uses a single multi-AZ Amazon RDS for PostgreSQL database instance to store and update active driver coordinates and trip states. During peak hours, driver mobile applications update their GPS coordinates every 3 seconds, causing the database CPU utilization to exceed 90%. Simultaneously, passenger applications run frequent read-heavy geospatial queries to locate nearby drivers, resulting in query timeouts. The company needs an architectural improvement that reduces database CPU utilization, provides sub-millisecond latency for location queries, and guarantees high availability and zero data loss for active session states in the event of an infrastructure failure. Which database and caching strategy should a solutions architect implement to resolve these performance issues?

  1. A
    Deploy an Amazon RDS Proxy in front of the PostgreSQL database instance to manage connection pooling, and deploy an RDS Read Replica in a separate Availability Zone. Configure passenger applications to run geospatial queries against the read replica, and route driver coordinate updates to the primary DB instance via the RDS Proxy.
  2. Migrate transient driver coordinate tracking and matchmaking queries to an Amazon ElastiCache for Redis cluster with Multi-AZ replication enabled. Use Redis geospatial commands to index coordinates and query nearby drivers. Configure the application to write only completed trip records and persistent transactional logs to the Amazon RDS PostgreSQL database.Answer
  3. C
    Migrate transient driver coordinate tracking to an Amazon ElastiCache for Memcached cluster. Modify the passenger application to retrieve raw coordinates from Memcached and compute geospatial proximity locally on client devices. Periodically write batch updates of driver coordinates from the Memcached cluster back to the Amazon RDS PostgreSQL database.
  4. D
    Migrate driver coordinate data to an Amazon DynamoDB table and deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache read requests. Configure the matchmaking service to perform geospatial queries against DAX using the DynamoDB Geo Library, writing coordinate updates directly to the DynamoDB table.

Answer

Migrate transient driver coordinate tracking and matchmaking queries to an Amazon ElastiCache for Redis cluster with Multi-AZ replication enabled, utilizing Redis geospatial commands for location queries, and writing only persistent transactional records to the Amazon RDS PostgreSQL database.
Deploying an Amazon ElastiCache for Redis cluster is the optimal solution. It offloads transient, high-velocity coordinate updates and geospatial queries from the relational database to an in-memory data store. Redis geospatial data structures allow sub-millisecond spatial indexing and matchmaking queries, and Multi-AZ replication ensures high availability and durability of the session data.

Step-by-Step Solution

1
Analyze the bottleneck and data requirements.
Identify that the primary issue is the write-heavy updates (every 3 seconds per driver) combined with read-heavy geospatial queries on transient data (driver coordinates) causing CPU exhaustion on RDS PostgreSQL.
Determining whether the data is transient or persistent dictates whether it belongs in a relational database or a caching/in-memory tier.
2
Evaluate caching and in-memory options for geospatial operations.
Determine that Amazon ElastiCache for Redis natively supports geospatial indexing and querying with sub-millisecond latency.
Using native cache engine features minimizes application complexity and meets performance requirements.
3
Assess high availability and reliability requirements.
Rule out Memcached because it does not support replication, Multi-AZ failover, or persistence. Select ElastiCache for Redis with Multi-AZ replication to ensure zero data loss and high availability.
Session states and driver coordinates must be highly available and resilient to node failures.
4
Formulate the database offloading strategy.
Redirect high-frequency updates and queries to Redis, and write only transactional, persistent data (like completed trips) to RDS PostgreSQL.
Offloading transient, high-velocity writes from the relational database resolves the CPU bottleneck on the RDS instance.

Key Concept

Offloading high-velocity geospatial writes and transient session data to ElastiCache for Redis to resolve relational database CPU bottlenecks while maintaining high availability.
Rate this question

Topics

Improving Database and Caching Efficiency