Amazon ElastiCache | Deep Dive.

Amazon ElastiCache - Deep Dive.

Scope:

• Intro,
• Two Supported engines,
• Key Features,
• Engines,
• Performance,
• Cluster Architecture,
• Durability,
• Scaling,
• Security,
• Monitoring,
• Sample Architectures,
• Redis vs Memcached (+When to Use which).
• AWS CLI Sample,
• Best practices.

Intro:

• Amazon ElastiCache is a fully managed in-memory data store and caching service provided by Amazon Web Services (AWS). 
• Amazon ElastiCache is designed to:
•  Provide high-performance, 
• Low-latency access to data, 
• Significantly improving application performance by retrieving information from a fast in-memory cache instead of a slower disk-based database.
• Amazon ElastiCache is a powerhouse to speed up applications.

Two Supported engines 

• Redis (popular choice: caching + pub/sub + data structures)
• Memcached (simpler, high-performance distributed cache)

It’s widely used to reduce

• Latency,
• Offload databases,
• And power real-time apps.

 Key Features

1. Engines

• Redis:
• In-memory key-value store with rich data structures (strings, lists, sets, sorted sets, hashes, streams).
• Supports replication, clustering, persistence (AOF/RDB), pub/sub messaging, and Lua scripting.
• Best for caching + real-time apps (leaderboards, chat, session stores).
• Memcached:
• Simpler key-value cache, pure in-memory (no persistence).
• Easy horizontal scaling (sharding).
• Best for basic caching layer with very high throughput.

2. Performance

• Sub-millisecond latency.
• Millions of reads/writes per second.
• Removes load from backend DB (Aurora, RDS, DynamoDB, etc.).

3. Cluster Architecture

• Redis:
• Standalone: Single node.
• Replication group: Primary + replicas (up to 5 per shard).
• Cluster mode enabled: Sharded across multiple primaries, each with replicas.
• Memcached:
• Multiple independent nodes, client-side sharding.

4. Durability

• Redis only:
• Persistence (RDB snapshots, AOF logs).
• Replication for HA.
• Auto-failover in Multi-AZ deployments.
• Memcached: No persistence, in-memory only.

5. Scaling

• Vertical scaling: Change instance size.
• Horizontal scaling:
• Redis cluster sharding.
• Memcached client-side partitioning.
• Online resharding supported in Redis.

6. Security

• VPC only (no public internet access).
• Encryption in-transit + at-rest (Redis).
• Authentication (Redis AUTH or IAM auth).
• Security groups control access.

7. Monitoring

• Amazon CloudWatch metrics: CPU, memory, eviction count, replication lag.
• Enhanced Monitoring for Redis slow logs, latency, command stats.

Sample Architectures

Insights:

 E-Commerce Site (with Aurora)

1. User browses products → request hits API Gateway → App (EKS/ECS/EC2).
2. App checks ElastiCache Redis for product details.
• If cached → return immediately.
• If not cached → fetch from Aurora → store in Redis for next time.
3. Checkout still goes to Aurora (ensures strong consistency).

Result: 70–90% fewer Aurora reads.

 Real-Time Chat App

• Redis Pub/Sub used to fan out chat messages to connected users.
• In-memory → near real-time (<1 ms).

 Gaming Leaderboard

• Redis Sorted Sets track scores in real-time.
• Querying top 10 players = O(log N) performance.

Analytics / Session Store

• Redis keeps user sessions in-memory (faster than hitting DB).
• Common in web/mobile apps.

 Redis vs Memcached – When to Use which

Feature	Redis	Memcached
Data structures	Strings, lists, sets, hashes, streams, sorted sets	Simple key-value only
Persistence	Yes (RDB, AOF)	No
Replication & HA	Yes (Multi-AZ, replicas)	No
Clustering	Yes (sharding)	Client-managed
Use cases	Caching + session store + analytics + pub/sub + leaderboards	Simple, large, distributed cache

Most new apps → Redis is preferred.

 Hands-On Setup

AWS Console (Redis Example)

1. Go to ElastiCache → Create Cluster.
2. Choose Redis.
3. Deployment:
• Cluster mode disabled → 1 primary + replicas.
• Cluster mode enabled → sharded architecture.
4. Instance type (e.g., cache.r6g.large).
5. Multi-AZ → enable replication + automatic failover.
6. Set VPC + subnet groups + security groups.
7. Configure encryption & Redis AUTH.

twtech should get:

• Primary endpoint (writes).
• Reader endpoint (load balances across replicas).

AWS CLI Sample

# bash

aws elasticache create-replication-group \

  --replication-group-id twtech-redis-cluster \

  --replication-group-description "twtech Redis Cluster for Caching" \

  --engine redis \

  --engine-version 7.0 \

  --cache-node-type cache.r6g.large \

  --num-node-groups 2 \

  --replicas-per-node-group 1 \

  --multi-az-enabled \

  --automatic-failover-enabled

Best Practices

• Use Redis over Memcached unless twtech has a legacy use case.
• Enable Multi-AZ with auto-failover for production.
• Apply TTL (time-to-live) to cache keys to avoid stale data.
• Use reader endpoint for scaling reads across replicas.
• Monitor evictions + replication lag.
• Keep cache close to app servers (same region + VPC).