Q54 — AWS SAA-C03 Ch.16

Question 54 of 100 | ← Chapter 16

Q1254. A gaming company has a web application that displays game scores. The application runs on Amazon EC2 instances behind an Application Load Balancer (ALB).The application stores data in an Amazon RDS for MySQL database.Users are experiencing long delays and interruptions that are caused by degraded database read performance.The company wants to improve the user experience.Which solution will meet this requirement?

Correct Answer: A. Use an Amazon ElastiCache (Redis OSS) cache in front of the database.

Explanation

The best solution to improve database read performance and reduce delays for the gaming company's web application is Option A: Use Amazon ElastiCache (Redis OSS) in front of the database. Here's the detailed analysis:Key Requirements:Improve read performance (users experience delays due to slow database reads). Reduce interruptions (likely caused by database bottlenecks). Maintain compatibility with the existing EC2 + ALB + RDS MySQL architecture.Analysis of Options:A. Amazon ElastiCache (Redis OSS) CacheBest Choice:Caches frequently accessed data (e.g., game scores, user profiles) in memory, reducing RDS read load. Significantly improves read performance (Redis provides sub-millisecond latency). Easy to integrate with the existing application (EC2 instances can query Redis before falling back to RDS). Cost-effective (ElastiCache scales horizontally and is cheaper than over-provisioning RDS).B. Amazon RDS ProxyNot the best for read performance:RDS Proxy improves connection management (reduces connection overhead, prevents connection storms).Does not directly speed up read queries--it helps with scaling writes/connections but doesn't cache data. Better suited for write-heavy workloads or connection pooling issues.C. Migrate to AWS LambdaOverkill and incompatible:Lambda is serverless, but the application already runs on EC2 (rewriting it may introduce new complexities).Does not solve the read performance issue--Lambda would still query RDS unless paired with a cache.Cold starts could worsen latency for some users.D. Amazon Aurora Global DatabaseUnnecessary for this use case:Aurora Global Database is for multi-region disaster recovery (low-latency reads across regions). Does not help with read performance in a single region (the issue is likely local RDS bottlenecks, not regional latency).Adds complexity (requires Aurora, not standard MySQL).Why Option A is Superior:Directly addresses read performance (caching is the fastest way to serve repeated queries). Minimal changes to the existing architecture (just add Redis between the app and RDS). Proven solution for gaming leaderboards (Redis is widely used for high-speed score tracking).Scalable (ElastiCache can auto-scale as traffic grows).Implementation Steps for Option A:Deploy Amazon ElastiCache (Redis):Choose Redis (Open Source) for compatibility with MySQL-like workloads. Configure a Cluster Mode Enabled setup for high availability.Modify the Application:Update the EC2 instances to check Redis first for game scores. If data is not in Redis (cache miss), query RDS and populate the cache. Use TTL (Time-To-Live) for cached data to ensure freshness.Optimize Cache Performance:Use Redis pipelines for bulk queries.Monitor cache hit rates with Amazon CloudWatch.Scale as Needed:Add read replicas to Redis if read load increases further.Final Answer:AThis solution provides the fastest read performance improvements with the least disruption to the existing architecture.