AWS - Elastic Cache

Amazon ElastiCache is a fully managed, in-memory caching service that helps you speed up application performance by retrieving data from a fast, managed cache instead of repeatedly querying a slower database (like RDS or DynamoDB).

In short: It’s like keeping your most frequently used data in RAM, so your apps can access it within microseconds instead of milliseconds.

How It Works

Normally, your app talks directly to a database:

App → Database → Response (slow)

With ElastiCache, you add a caching layer:

App → ElastiCache (cache hit → super fast)
     ↓
     Database (cache miss → slower, then store in cache)

This pattern is called “Cache-aside” (lazy loading).

Core Components

Component	Description
Cache Cluster	A collection of one or more cache nodes (instances).
Cache Node	A single in-memory instance (like an EC2 instance, but optimized for caching).
Parameter Group	Defines runtime settings (similar to DB parameter groups).
Subnet Group	Defines which subnets your cache can run in (for VPC).
Replication Group	Manages primary/replica nodes for high availability (Redis only).
Engine	ElastiCache supports Redis and Memcached.

---

Supported Engines

Redis

• Open-source, key-value data store with advanced features.

• Supports:

  • Data persistence

  • Pub/Sub messaging

  • Replication and failover

  • Cluster mode for sharding

  • Encryption and authentication

Best for: real-time analytics, session stores, leaderboards, caching with persistence

---

Memcached

• Simple, in-memory key-value store designed purely for caching.

• No persistence, no replication, no complex data structures.

• Scales horizontally by adding/removing nodes.

Best for: simple caching, ephemeral data, distributed caching

---

Redis vs Memcached Comparison

Feature	Redis	Memcached
Data Structures	Strings, lists, sets, sorted sets, hashes, bitmaps, streams	Strings only
Persistence	Yes (RDB, AOF)	No
Replication	Yes	No
High Availability (Multi-AZ)	Yes	No
Cluster Mode	Yes (sharding)	Yes (client-side)
Pub/Sub Messaging	Supported	No
Use Case	Caching + real-time analytics + message queues	Simple, fast caching

---

Common Caching Patterns

Pattern	Description
Cache-aside (Lazy loading)	App checks cache first → if data missing → fetch from DB → store in cache
Write-through	Data written to cache and DB simultaneously
Write-behind	Data written to cache first → asynchronously written to DB
Session store	Store user session data (Redis supports TTLs)
Pub/Sub	Redis channels used for message broadcasting

---

Example Architecture: RDS + ElastiCache + Application

Let’s walk through a common real-world architecture.

Use Case:

Your application reads product details from an RDS database frequently. To reduce latency and DB load, you introduce an ElastiCache Redis cluster.

---

Flow

1. User requests product info → App Server checks ElastiCache Redis.

2. If cache hit, return instantly from cache (fast).

3. If cache miss, app queries RDS, then stores the result in Redis for next time.

4. Optional: Set TTL (Time-to-Live) to expire old cache data.

---

Architecture Components

Component	Role
Application (EC2 / ECS / Lambda)	Queries Redis for frequently accessed data
ElastiCache (Redis Cluster)	In-memory cache, primary + replicas for HA
Amazon RDS (MySQL/PostgreSQL)	Persistent storage for data
Amazon CloudWatch	Monitors cache metrics (CPU, memory, evictions)
IAM + Security Groups	Restrict access (only app servers can access cache)

---

Architecture Diagram (text form)

                +-------------------------+
                |     Application Tier    |
                |  (EC2 / ECS / Lambda)   |
                +-----------+-------------+
                            |
                            | (Check cache first)
                            v
                  +------------------+
                  | ElastiCache Redis|
                  |  In-memory cache |
                  +--------+---------+
                           |
                (Cache miss → Query DB)
                           |
                           v
                    +--------------+
                    | Amazon RDS   |
                    | MySQL / Postgres |
                    +--------------+

---

Key Benefits

Performance: Sub-millisecond latency
Scalability: Easily scale in/out
Cost saving: Reduce database load & cost
High availability: Multi-AZ + automatic failover
Managed: AWS handles patching, backups, and monitoring

---

Example (Boto3 – Python)

import redis

# Connect to Redis cluster
r = redis.StrictRedis(
    host='mycachecluster.xxxxxx.ng.0001.use1.cache.amazonaws.com',
    port=6379,
    decode_responses=True
)

# Check cache
value = r.get("product:123")

if not value:
    # Simulate DB query
    value = "Product data from DB"
    # Store in cache for 1 hour
    r.setex("product:123", 3600, value)

print(value)

---

When to Use ElastiCache

Use ElastiCache when you need:

• Sub-millisecond access to frequently read data

• To reduce pressure on databases (RDS, DynamoDB)

• To store session or stateful data for apps

• To implement leaderboards, counters, or pub/sub systems

• To scale real-time analytics dashboards

---------------------------------------------------------------------------------------------------------------------------

Here’s a description of an architecture diagram for Amazon ElastiCache (Redis) integrated with an application and RDS:

Title: Amazon ElastiCache Integration Architecture

Components:

1. User / Client

   • Initiates request to the application.

2. Application Tier (EC2 / ECS / Lambda)

   • Receives user requests.

   • Checks the ElastiCache Redis cluster for cached data.

   • If data exists (cache hit), returns immediately.

   • If data does not exist (cache miss), queries RDS and then stores result in cache.

3. Amazon ElastiCache (Redis Cluster)

   • Acts as in-memory cache layer.

   • Stores frequently accessed data with TTL (Time-to-Live).

   • Optional: Redis replicas for high availability.

4. Amazon RDS (MySQL / PostgreSQL)

   • Persistent data storage.

   • Queried only on cache misses.

5. Amazon CloudWatch

   • Monitors cache and database performance metrics (CPU, memory, connections, evictions).

6. IAM & Security Groups

   • Restrict access between application, cache, and database.

Data Flow:

1. User request → Application Tier

2. Application → Check ElastiCache Redis

   • Cache Hit → Return Data

   • Cache Miss → Query RDS → Store Data in Redis → Return Data

3. Monitoring and metrics via CloudWatch.

Diagram Layout :

Optional Enhancements:

• Multi-AZ Redis replication group.

• Read replicas in RDS for read-heavy workloads.

• Redis cluster mode enabled for sharding large datasets.

This architecture provides high performance, scalability, and reduced database load using ElastiCache as an in-memory caching layer.