Azure Cache for Redis

Azure Cache for Redis is a fully managed, in-memory data store based on the open-source Redis engine. It provides sub-millisecond response times, making it ideal for caching, session management, real-time analytics, and message brokering. This lesson covers Redis fundamentals, Azure Cache tiers, common patterns, and best practices.

---

What Is Redis?

Redis (Remote Dictionary Server) is an open-source, in-memory data structure store. Unlike traditional databases that persist data to disk, Redis keeps data in memory, enabling extremely fast reads and writes.

Redis Data Structures

Structure	Description	Example Use Case
Strings	Simple key-value pairs	Caching, counters
Hashes	Maps of fields and values	User profiles, product details
Lists	Ordered collections	Activity feeds, queues
Sets	Unordered collections of unique elements	Tags, unique visitors
Sorted Sets	Sets ordered by a score	Leaderboards, rate limiting
Streams	Append-only log structures	Event streaming, messaging
HyperLogLog	Probabilistic cardinality estimation	Unique visitor counts
Bitmaps	Bit-level operations on strings	Feature flags, daily active users
Geospatial	Coordinates with distance calculations	Nearby locations, delivery tracking

---

Azure Cache for Redis Tiers

Tier	Description	Use Case
Basic	Single node, no SLA, no replication	Development and testing
Standard	Two-node replicated (primary + replica), 99.9% SLA	Production workloads
Premium	Clustering, VNet, persistence, geo-replication, 99.9% SLA	Enterprise workloads
Enterprise	Redis Enterprise with RediSearch, RedisJSON, RedisTimeSeries, RedisBloom	Advanced data processing
Enterprise Flash	Redis Enterprise on NVMe flash + DRAM	Large datasets with lower cost

Tier Comparison

Feature	Basic	Standard	Premium	Enterprise
SLA	None	99.9%	99.9%	99.99%
Replication	No	Yes (primary + replica)	Yes	Yes (active-active)
Clustering	No	No	Up to 10 shards	Up to 500 shards
VNet integration	No	No	Yes	Yes
Persistence	No	No	RDB + AOF	RDB + AOF
Geo-replication	No	No	Passive (async)	Active (multi-region reads and writes)
Max memory	53 GB	53 GB	1.2 TB	2 TB+
Redis modules	No	No	No	RediSearch, RedisJSON, RedisTimeSeries, RedisBloom

---

Common Caching Patterns

Cache-Aside (Lazy Loading)

The most common caching pattern:

flowchart TD
  A["Application checks cache for data"] --> B{"Cache hit?"}
  B -->|"HIT"| C["Return cached data"]
  B -->|"MISS"| D["Read from database"]
  D --> E["Store the result in cache with a TTL"]
  E --> F["Return data to the caller"]

def get_product(product_id):
    # 1. Check cache
    cached = redis.get(f"product:{product_id}")
    if cached:
        return json.loads(cached)

    # 2. Cache miss — read from database
    product = db.query("SELECT * FROM products WHERE id = ?", product_id)

    # 3. Store in cache with 1-hour TTL
    redis.setex(f"product:{product_id}", 3600, json.dumps(product))

    return product

Write-Through

Write to the cache and database simultaneously:

flowchart TD
  A["Application writes to cache"] --> B["Cache writes to database"]
  B --> C["Both are always in sync"]

Higher write latency (two writes), but cache is always warm.

Write-Behind (Write-Back)

Write to the cache immediately; asynchronously write to the database later:

flowchart TD
  A["Application writes to cache"] --> B["Cache acknowledges immediately"]
  B --> C["Background process writes to database"]

Lowest write latency, but risk of data loss if the cache fails before the database write.

---

Session Management

Redis is widely used for storing HTTP session data in web applications:

graph LR
  U["User"] --> LB["Load Balancer"]
  LB --> A["Web Server A (reads session from Redis)"]
  LB --> B["Web Server B (reads session from Redis)"]
  LB --> C["Web Server C (reads session from Redis)"]