Designing Microservices Caching with Redis Write‑Through

TL;DR
– Write‑through keeps Redis and the primary DB in lockstep, eliminating most stale‑read bugs.
– Double‑write adds 2‑5 ms latency per write, but you reap 90 %+ read‑latency cuts at scale.
– Idempotency keys + retry loops protect against partial failures.
– Warm the cache on service start or via event‑driven “populate” jobs to avoid cold spikes.
– Monitor hit‑ratio, write‑error rate and latency percentiles; alert on drift between cache and DB.

Before you start, you need:

• A running Redis 7.0 cluster (or Sentinel) with AOF persistence enabled.
• Access to a relational store (PostgreSQL 15 or MySQL 8.0).
• Go 1.22 (or Java 21 / Python 3.12) toolchain installed.
• Familiarity with HTTP microservice patterns and basic Docker/Kubernetes concepts.

The Challenge of Caching in a Microservices Architecture

Why Traditional Caching Patterns Fail at Scale

Imagine a popular SaaS platform that suddenly spikes to 200 k RPS. Its cache‑aside layer sits in front of a monolithic DB. Every cache miss triggers a synchronous DB read, flooding the database and causing time‑outs. The result? users see “500 Internal Server Error” and the engineering on‑call rotates endlessly.

Legacy cache‑aside works when traffic is predictable and the data model is simple. In a distributed microservice world, each service owns its own data slice, yet many share the same Redis cluster. Miss‑driven bursts, uneven key popularity, and cross‑service writes quickly overwhelm the pattern.

The Latency‑Consistency Trade‑off in Distributed Systems

Every microservice balances two opposing forces: low latency for reads and strong consistency across replicas. Cache‑aside leans toward latency, accepting occasional stale data. Write‑behind leans toward write throughput, risking data loss on crashes. Write‑through sits in the middle, guaranteeing that a successful write to Redis also persists to the source of truth—no surprise “ghost records” later.

The trade‑off is explicit: you accept a few extra milliseconds on each write to keep reads fast and consistent. Netflix’s engineering blog notes the overhead sits around 2‑5 ms per write, yet read latency drops by 90 % and DB load collapses by 99 %. In practice, that extra time buys you simplicity in error handling and eliminates many race conditions.

Redis Write‑Through Pattern: Core Concepts

How Write‑Through Differs from Cache‑Aside and Write‑Behind

Cache‑aside follows a read‑first approach: look in Redis, fall back to DB, then populate the cache. Writes go straight to the DB, and the cache is refreshed later—often via an explicit Invalidate call.

Write‑behind swaps the order: the service writes to Redis, queues a background job, and eventually syncs to the DB. If the background worker crashes, data may be lost.

Write‑through flips the script. The service sends the payload to a Cache Manager that writes to Redis and the primary database in the same transaction (or logical unit). Only after both succeed does the request return to the client.

The Role of the Cache as the System of Record

When Redis becomes the write‑through path, it effectively acts as the system of record for that entity. That does not mean you abandon the relational DB; the DB still holds the canonical schema, supports reporting, and provides ACID guarantees. Redis, however, stores the hot subset of data that services read most often. By treating Redis as the authoritative source for those hot keys, you avoid “cache‑stale‑after‑write” bugs entirely.

Architecting the Write‑Through Layer

Component Design: Cache Manager, DAO, and Synchronizer

Below is a high‑level component diagram.

graph TD
    A[API Gateway] --> B[Service Handler]
    B --> C[Cache Manager]
    C --> D[Redis (Write‑Through)]
    C --> E[DAO (PostgreSQL)]
    D -.-> F[Synchronizer (Background Retry)]
    E -.-> F
    F --> D
    F --> E
    style C fill:#f9f,stroke:#333,stroke-width:2px
    style F fill:#bbf,stroke:#333,stroke-width:2px

• Cache Manager: Exposes Get, Put, Delete. Handles idempotency keys, retries, and error classification.
• DAO: Plain Golang/Java/Python data‑access object that talks to PostgreSQL/MySQL.
• Synchronizer: A lightweight worker that retries failed DB writes and cleans up “orphan” cache entries.

Handling Concurrent Writes and Race Conditions

Suppose two instances of UserService update the same user profile simultaneously. Without coordination, the later write could overwrite the earlier one in Redis while the DB accepts a different order, creating drift.

A common guard is optimistic locking using a version field (etag). Each write includes the expected version; the DAO rejects stale updates. The Cache Manager propagates the new version back to Redis in the same call.

Another guard is distributed locks (e.g., RedLock). Acquire a lock on user:{id} before executing the write‑through transaction. Keep the lock short (≤50 ms) to avoid bottlenecks.

Implementation Blueprint

Code Walkthrough: A Service in Go

Below is a complete, production‑ready snippet that demonstrates:

1. Idempotency via a UUID key stored in Redis (write:token:{id}).
2. Synchronous double write with proper error handling.
3. Automatic retry using exponential back‑off (github.com/cenkalti/backoff/v4).

// main.go – Go 1.22
package main

import (
    "context"
    "database/sql"
    "encoding/json"
    "errors"
    "fmt"
    "log"
    "time"

    "github.com/cenkalti/backoff/v4"
    "github.com/go-redis/redis/v9"
    _ "github.com/lib/pq"
)

// ---------- Configuration ----------
const (
    redisAddr      = "redis://redis-master:6379"
    postgresDSN    = "host=postgres user=app password=secret dbname=app sslmode=disable"
    writeTimeout   = 3 * time.Second
    idempotencyTTL = 10 * time.Minute
)

// ---------- Data Model ----------
type User struct {
    ID        string `json:"id"`
    Name      string `json:"name"`
    Email     string `json:"email"`
    Version   int64  `json:"version"` // optimistic lock field
    UpdatedAt int64  `json:"updated_at"`
}

// ---------- Global Clients ----------
var (
    rdb *redis.Client
    db  *sql.DB
)

func initClients() error {
    opt, err := redis.ParseURL(redisAddr)
    if err != nil {
        return fmt.Errorf("redis url parse: %w", err)
    }
    rdb = redis.NewClient(opt)

    db, err = sql.Open("postgres", postgresDSN)
    if err != nil {
        return fmt.Errorf("postgres open: %w", err)
    }
    // Verify connections
    if err = rdb.Ping(context.Background()).Err(); err != nil {
        return fmt.Errorf("redis ping: %w", err)
    }
    if err = db.Ping(); err != nil {
        return fmt.Errorf("postgres ping: %w", err)
    }
    return nil
}

// ---------- Cache Manager ----------
type CacheManager struct {
    redis *redis.Client
}

// Put writes to Redis and PostgreSQL atomically (logical unit)
func (c *CacheManager) Put(ctx context.Context, u User, idemKey string) error {
    // Idempotency guard – ensure the same request never runs twice
    tokenKey := fmt.Sprintf("write:token:%s", idemKey)
    set, err := c.redis.SetNX(ctx, tokenKey, "1", idempotencyTTL).Result()
    if err != nil {
        return fmt.Errorf("redis setnx: %w", err)
    }
    if !set {
        // Token already exists – treat as already processed
        return nil
    }

    // Serialize user for Redis
    data, err := json.Marshal(u)
    if err != nil {
        return fmt.Errorf("marshal user: %w", err)
    }
    redisKey := fmt.Sprintf("user:%s", u.ID)

    // Define the operation that writes both places
    operation := func() error {
        // 1️⃣ Write to Redis
        if err = c.redis.Set(ctx, redisKey, data, 0).Err(); err != nil {
            return fmt.Errorf("redis set: %w", err)
        }
        // 2️⃣ Write to PostgreSQL
        query := `
            INSERT INTO users (id, name, email, version, updated_at)
            VALUES ($1,$2,$3,$4,$5)
            ON CONFLICT (id) DO UPDATE SET
                name = EXCLUDED.name,
                email = EXCLUDED.email,
                version = EXCLUDED.version,
                updated_at = EXCLUDED.updated_at
            WHERE users.version < EXCLUDED.version;`
        _, err = db.ExecContext(ctx, query,
            u.ID, u.Name, u.Email, u.Version, time.Now().Unix())
        if err != nil {
            return fmt.Errorf("postgres exec: %w", err)
        }
        return nil
    }

    bo := backoff.NewExponentialBackOff()
    bo.InitialInterval = 100 * time.Millisecond
    bo.MaxElapsedTime = writeTimeout

    if err = backoff.Retry(operation, bo); err != nil {
        // Compensating action – invalidate Redis entry to keep consistency
        _ = c.redis.Del(ctx, redisKey).Err()
        return fmt.Errorf("write‑through failed after retries: %w", err)
    }
    return nil
}

// Get reads from Redis; on miss falls back to DB and warms the cache
func (c *CacheManager) Get(ctx context.Context, id string) (User, error) {
    var u User
    redisKey := fmt.Sprintf("user:%s", id)

    val, err := c.redis.Get(ctx, redisKey).Result()
    if err == nil {
        if jsonErr := json.Unmarshal([]byte(val), &u); jsonErr == nil {
            return u, nil
        }
    }
    // Cache miss or corrupt payload – pull from DB
    row := db.QueryRowContext(ctx,
        `SELECT id, name, email, version, updated_at FROM users WHERE id=$1`, id)
    if scanErr := row.Scan(&u.ID, &u.Name, &u.Email, &u.Version, &u.UpdatedAt); scanErr != nil {
        return User{}, fmt.Errorf("db fetch: %w", scanErr)
    }
    // Warm cache asynchronously
    go func() {
        payload, _ := json.Marshal(u)
        _ = c.redis.Set(context.Background(), redisKey, payload, 0).Err()
    }()
    return u, nil
}

// ---------- Service Entry ----------
func main() {
    if err := initClients(); err != nil {
        log.Fatalf("init error: %v", err)
    }
    cm := &CacheManager{redis: rdb}
    ctx := context.Background()

    // Example write-through request
    user := User{
        ID:      "u-123",
        Name:    "Alice",
        Email:   "alice@example.com",
        Version: time.Now().Unix(),
    }
    idempotencyKey := "req-2e5f-20240627"

    if err := cm.Put(ctx, user, idempotencyKey); err != nil {
        log.Printf("write‑through error: %v", err)
    } else {
        log.Println("write‑through succeeded")
    }
}

Why this matters:

• The SetNX call guarantees the same request cannot be processed twice, even if the client retries.
• backoff.Retry limits the write window to three seconds, after which we roll back the Redis entry to keep consistency.
• The Get method populates the cache lazily, solving cold‑start problems for rarely accessed keys.

💡 Pro Tip: Store the idempotency token with a TTL slightly longer than the maximum retry window. That prevents token leakage while still protecting against duplicate writes.

Configuring Redis for Durability and High Availability

1. Persistence – Enable AOF with appendfsync everysec. This provides near‑real‑time durability without the latency of every‑write sync.
   conf # redis.conf appendonly yes appendfsync everysec

2. RDB Snapshot – Keep a daily RDB file as a fallback for catastrophic AOF corruption.
   conf save 900 1 # every 15 minutes if at least 1 key changed

3. HA – Deploy a Redis Sentinel cluster (3 masters, 5 replicas). Sentinel monitors health and promotes a replica automatically.

bash # Launch Sentinel with Docker docker run -d --name sentinel \ -p 26379:26379 \ -v $(pwd)/sentinel.conf:/usr/local/etc/redis/sentinel.conf \ redis:7.0 redis-sentinel /usr/local/etc/redis/sentinel.conf

1. Cluster Mode – For >100 GB of hot data, enable sharding with Redis Cluster (3 shards, each with a replica).

bash # Start a 3‑node cluster docker run -d --name redis-0 -p 6379:6379 redis:7.0 --cluster-enabled yes --cluster-config-file nodes.conf

Idempotency and Retry Logic for Failed Writes

The snippet already demonstrates idempotency keys. In production, you often surface the token to the caller (e.g., via an Idempotency-Key HTTP header). If a client sees a 409 Conflict because the token already exists, it can safely re‑issue the request without causing a duplicate entry.

When the primary DB write fails after Redis succeeded, the Synchronizer you saw as a dashed arrow in the diagram will:

1. Pull the “pending” entry from a dedicated Redis list (write:pending).
2. Attempt the DB write with exponential back‑off.
3. On permanent failure (e.g., constraint violation), delete the Redis entry and publish an alert.

A minimal Go worker looks like this:

func backgroundSync(ctx context.Context) {
    for {
        id, err := rdb.LPop(ctx, "write:pending").Result()
        if err == redis.Nil {
            time.Sleep(2 * time.Second)
            continue
        }
        if err != nil {
            log.Printf("pending pop error: %v", err)
            continue
        }
        // fetch payload, attempt DB write, etc.
    }
}

Critical Trade‑offs and Operational Considerations

Performance Impact: The Double‑Write Penalty vs. Read Performance Gain

Every write now travels through two systems. Benchmarks on a 2‑vCPU EC2 instance show:

Contrast that with a read‑heavy workload where 95 % of requests are cache hits at 0.4 ms each. The net effect is a >90 % reduction in overall latency for the dominant path. Netflix’s numbers line up tightly—add 2–5 ms to each write, but you shave tens of milliseconds off millions of reads.

⚠️ Warning: If your write rate exceeds 10 k RPS, the double‑write may saturate the DB. In that regime, consider hybridizing with a write‑behind queue for low‑priority writes.

Dealing with Cold Starts and Cache Population

When a new service replica boots (e.g., in an autoscaling group), the first few requests hit the DB, creating a sudden spike. Mitigate this by:

• Pre‑warming: On container start, pull a list of hot keys from Redis (redis-cli SMEMBERS hot:user_ids) and call CacheManager.Get for each.
• Lazy Populate with TTL: Store a short TTL (e.g., 30 s) on rarely touched keys. The next request will fetch from DB, repopulate, and then enjoy a longer TTL.

# Example shell script to pre-warm
ids=$(redis-cli SMEMBERS hot:user_ids)
for id in $ids; do
  curl -s "http://service.internal/users/$id" > /dev/null
done

Monitoring Metrics: Hit Ratio, Latency Percentiles, and Write Errors

Set up Prometheus alerts:

# prom.yaml
- alert: RedisWriteThroughErrorRate
  expr: rate(redis_write_errors_total[5m]) > 0.01
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "High write‑through error rate"
    description: "More than 1% of write‑through ops failed in the last 5 minutes."

Key counters to expose from your Go service:

• redis_write_success_total / redis_write_errors_total
• db_write_success_total / db_write_errors_total
• cache_hit_ratio (hits / (hits + misses))

Dashboard a heat map of write latency to spot spikes that could indicate network congestion between your service and the Redis shard.

Advanced Patterns and When to Use Them

Combining Write‑Through with TTL and Write‑Behind Queues

A hybrid approach works well for high‑write, high‑read workloads where certain fields change frequently (e.g., a user’s “last_seen” timestamp). Store the mutable field in a write‑behind queue (Kafka 3.3) while the rest of the object stays in write‑through mode. The queue aggregates updates and flushes them to the DB every few seconds, reducing DB load without sacrificing read freshness.

// Pseudo‑code for hybrid field
if field == "last_seen" {
   // push to Kafka, skip DB write
   producer.Produce(topic, payload)
} else {
   cacheMgr.Put(ctx, obj, idemKey) // normal write‑through
}

Scenario Analysis: High‑Write vs. High‑Read Workloads

💡 Pro Tip: Use Redis keyspace notifications (notify-keyspace-events Ex) to listen for external DB changes (e.g., batch jobs) and invalidate affected keys automatically.

Common Errors & Fixes

Call to Action

If you found this guide useful, drop a comment below, share it with your team, or subscribe to the newsletter on nileshblog.tech for more deep‑dive articles on system design, Go performance tricks, and Kubernetes best practices.

My take:
Write‑through feels like “paying a small tax” for every write, but that tax buys you peace of mind. In my projects, the biggest post‑mortems stemmed from cache‑invalidation bugs, not from the extra milliseconds spent on double writes. Embrace the pattern where read latency matters more than the marginal write cost, and you’ll see both reliability and developer velocity improve dramatically.

Author Bio:
I’m Nilesh Raut, a Software Development Engineer with 2+ years of experience, specializing in Go, JavaScript, Python, Docker, Kubernetes, Git, Jenkins, microservices, and system design (LLD/HLD), backed by a strong foundation in data structures and algorithms. Alongside my engineering journey, I bring 4+ years of hands‑on experience in SEO, where I’ve worked extensively on content strategy, keyword research, technical SEO, and organic growth, helping products and businesses scale efficiently by aligning solid technology with search‑driven performance.