A financial service provider operates a real-time payment validation platform backed by an… — AWS Certified Solutions Architect - Professional

A financial service provider operates a real-time payment validation platform backed by an Amazon Aurora MySQL database cluster. During high-volume marketing campaigns, the platform experiences transaction failures due to database connection exhaustion and latency spikes, with database CPU utilization on the primary writer exceeding $90\%$ . The transaction validation workflow has two distinct database operations: user profile and ledger validation checks that require strong, up-to-date read-after-write consistency, and real-time audit logging combined with fraud-detection analytics queries that can tolerate eventual consistency of up to $10\text{ seconds}$ . The database currently runs on a provisioned Multi-AZ deployment without any reader instances. A Solutions Architect must optimize the database layer to resolve connection and CPU bottlenecks, minimize response latency, and maintain high availability during traffic spikes. Which two actions should the Solutions Architect implement to achieve these goals? (Select TWO.)

Deploy Amazon RDS Proxy between the application layer and the Aurora MySQL DB cluster to pool database connections.Answer
Modify the application configuration to route user profile and ledger validation queries to the Aurora primary cluster endpoint, and direct the fraud-detection analytics queries to the Aurora reader endpoint with Aurora Auto Scaling enabled.Answer
C
Deploy an Amazon ElastiCache for Memcached cluster to cache active validation session data, and enable Multi-AZ replication with automatic failover to prevent data loss.
D
Route the fraud-detection analytics queries to the standby instance of the database cluster to offload read operations from the primary writer instance.
E
Configure Amazon DynamoDB Accelerator (DAX) in front of the Aurora DB cluster to cache the relational user profiles and validation queries with microsecond latency.

Answer

Deploy Amazon RDS Proxy between the application layer and the Aurora MySQL DB cluster to pool database connections, and modify the application configuration to route user profile and ledger validation queries to the Aurora primary cluster endpoint, and direct the fraud-detection analytics queries to the Aurora reader endpoint with Aurora Auto Scaling enabled.

Deploying Amazon RDS Proxy allows the system to pool and share database connections, which prevents database connection exhaustion and reduces CPU utilization on the primary writer. Routing the user profile and ledger validation queries (which require strong consistency) to the primary writer cluster endpoint ensures read-after-write consistency, while offloading the eventual-consistency-tolerant fraud-detection queries to the Aurora reader endpoint (scaled automatically via Aurora Auto Scaling) resolves the CPU bottleneck and optimizes read performance.

Step-by-Step Solution

Address the database connection exhaustion and CPU spikes caused by connection overhead.

Implement Amazon RDS Proxy to pool and share database connections.

RDS Proxy reduces database CPU overhead by establishing a pool of reusable connections, eliminating the need to repeatedly open and close connections on the DB instances during traffic spikes.

Analyze the consistency requirements for the payment validation workflow.

Identify that user profile and ledger checks require strong read-after-write consistency, whereas fraud-detection analytics queries can tolerate up to 10 seconds of replication lag.

Queries requiring strong consistency must be routed to the writer endpoint (primary instance), while queries that can tolerate eventual consistency can be offloaded to readers.

Optimize the database cluster scaling to handle the offloaded read traffic.

Create Aurora Replicas (readers) and configure Aurora Auto Scaling based on metrics like CPU utilization.

Aurora Auto Scaling dynamically adjusts the number of reader instances to accommodate surge read traffic, ensuring high availability and cost optimization.

Evaluate and discard invalid architecture options.

Discard Memcached for replication, standby instances for reads, and DAX for relational databases.

Memcached does not support multi-AZ replication or failover; standby nodes in traditional Multi-AZ cannot serve read traffic; DAX is exclusive to DynamoDB.

Key Concept

Database connection pooling and read replica offloading with scaling adjustments based on query consistency requirements.

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics