Exam AWS Certified Solutions Architect - Associate SAA-C02 topic 1 question 394 discussion

"Modify the website" to check the cache before querying the database read endpoints.

In my opinion, B does not "reduce the replication lag", that strategy assumes that read replicas will be more up to date than the ElasticCache cache. So, it's not a solution. I think Answer is A

A should be the minimal code change, just change the db connection string for B, you will need to check if the target is existing in cache, if not then get from db and put back to elasticcache. These are the code change needed

for REDIS. You have to rewrite the entire application, which is based on a SQL connector...

WRONG! It is A. Understand the RR does not have the latest content. You are building the cache on the RR... how can the cache have the new content if the main source (RR) itself does not have...it does not improve the situation.

If we are talking about code changes, I think the order will be like this: 1. DynamoDB (most changes since you are going from relational to non-relation DB) 2. ElastiCache (every method in your app needs to implement caching) 3. Aurora and MySQL inside EC2 don't require any code changes

Aurora replication lag: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Replication.html The primary instance and the Aurora Replicas in the DB cluster all see the data in the cluster volume as a single logical volume. As a result, all Aurora Replicas return the same data for query results with minimal replica lag. This lag is usually much less than 100 milliseconds after the primary instance has written an update. Replica lag varies depending on the rate of database change. That is, during periods where a large amount of write operations occur for the database, you might see an increase in replica lag. ============== Replication from the primary DB cluster to all secondaries is handled by the Aurora storage layer rather than by the database engine, so lagtime for replicating changes is minimal—typically, less than 1 second. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.html

This is not the reason to pick A.

Elasticache can also serve RDS SQL databases: Memcached: Amazon ElastiCache is an ideal front-end for data stores like Amazon RDS or Amazon DynamoDB, providing a high-performance middle tier for applications with extremely high request rates and/or low latency requirements https://aws.amazon.com/elasticache/faqs/ Redis: You will implement a cache-aside strategy using Amazon ElastiCache for Redis on top of a MySQL database. https://aws.amazon.com/getting-started/hands-on/boosting-mysql-database-performance-with-amazon-elasticache-for-redis/