2.4.1.3. Caching Strategies for Databases (ElastiCache, CloudFront)

2.4.1.3. Caching Strategies for Databases (ElastiCache, CloudFront)

💡 First Principle: Implementing a caching layer is a critical strategy to reduce load on primary databases, minimize latency for frequently accessed data, and improve overall application responsiveness and scalability.

Scenario: A popular e-commerce website experiences high read traffic to its product catalog data stored in "Amazon Aurora MySQL". This causes performance bottlenecks during peak hours. The product catalog data is updated infrequently. The architect needs to implement a caching layer to reduce the load on the database and improve application responsiveness.

Caching is a powerful technique to enhance application performance and reduce database costs by storing frequently accessed data in a fast, in-memory store.

• "Amazon ElastiCache" ("Redis", "Memcached"): A fully managed, in-memory data store service.
  • Practical Relevance:
    • Database Caching: Stores query results, reducing repetitive reads on the database. Ideal for read-heavy workloads where data doesn't change frequently.
    • Session Management: Stores user session data for web applications, enabling horizontal scaling of stateless application servers.
    • Leaderboards/Gaming: High-speed storage for real-time data.
  • "Redis": Supports more complex data structures (lists, sets, hashes), pub/sub, persistence, and "Multi-AZ" deployments. Often preferred for more advanced use cases.
  • "Memcached": Simpler, multi-threaded, best for basic object caching.
• "Amazon CloudFront": A global content delivery network ("CDN").
  • Practical Relevance: Primarily for caching web content (static assets, API responses). Can cache dynamic content by forwarding requests to origins. Reduces load on application servers and databases by serving content from edge locations.
• Application-level Caching: Implementing caching directly within your application code.
  • Practical Relevance: Useful for very small, localized caches, but often less scalable or manageable than dedicated services like "ElastiCache".

Visual: Caching Strategies for Databases

⚠️ Common Pitfall: Neglecting cache invalidation. If the primary data source is updated, the cache must be invalidated or updated to avoid serving stale data to users. A poor invalidation strategy can lead to data consistency issues.

Caching Patterns and Choices the Exam Tests:

• Caching strategies: Lazy loading (cache-aside): the application checks the cache, reads the database on a miss and writes the result into the cache; only requested data is cached and a node failure just means misses, but data can be stale until its TTL expires. Write-through: every database write also updates the cache, so the cache is never stale for written keys but caches data that may never be read. Combine them, and set TTLs deliberately (a TTL of "never expire" lets stale data persist indefinitely). Write-behind (cache first, flush later) risks losing data if the cache fails.
• Redis vs. Memcached: Redis offers rich structures (sorted sets for ranked leaderboards, hashes, lists), replication, Multi-AZ failover and persistence; Memcached is simple, multi-threaded object caching with no replication. A migration from self-managed Redis maps to ElastiCache for Redis to offload patching, failover, backup and scaling with no application change. Session state externalized for stateless web tiers needs sub-millisecond access, which also points to ElastiCache.
• Cache vs. more database capacity: If a few expensive queries over rarely changing data dominate load, cache their results; adding read replicas or rewriting queries still executes every request against the database.
• "DynamoDB Accelerator (DAX)": A fully managed, API-compatible in-memory cache for DynamoDB that cuts read latency from milliseconds to microseconds for repeated reads of hot items, with no application redesign beyond using the DAX client, and lets you lower provisioned RCUs. It serves eventually consistent reads; strongly consistent reads pass through to DynamoDB. A GSI or more RCUs does not accelerate repeated "GetItem" calls.
• Caching in front of the application: "API Gateway" stage-level caching serves identical requests from the cache instead of invoking "Lambda" and the database (TTL default 300 seconds, adjustable), which is the direct fix for a slow, rarely changing backend query behind an API. "AWS AppSync" has a native server-side cache (enabled on the API, per-resolver or full-request caching with a TTL) for GraphQL responses. Lambda memory/provisioned concurrency and Regional endpoints address compute and cold starts, not repeated backend queries.

Key Trade-Offs:

• Performance/Features ("Redis") vs. Simplicity ("Memcached"): "Redis" offers more features like persistence, replication, and complex data types, but "Memcached" is simpler and can be slightly more performant for simple key-value caching due to its multi-threaded nature.

Reflection Question: Why would "Amazon ElastiCache for Redis" be the most suitable caching solution for an e-commerce website with high read traffic to its product catalog data (infrequently updated), and how would it interact with the "Aurora" database to offload read traffic and improve application responsiveness?