Pattern QuestDesign Pattern · Java ⇄ GoDesign Patterns · Java ⇄ Go

#redis
#caching
#high-concurrency
#spring-boot

Redis cache stampede trong flash sale – cách ngăn hệ thống sậpRedis cache stampede in flash sales – how to keep the system alive

Giải thích cache stampede khi traffic bùng nổ và đưa ra các giải pháp thực tiễn cho Java Spring Boot và Go.Explain cache stampede under traffic spikes and give practical fixes for Java Spring Boot and Go.

8 tháng 11, 2026November 8, 20266 phút đọc6 min read000

Mục lụcContents· 12

Tình huống thực tế
Nguyên nhân: cache stampede là gì?
Mô hình cache naïve (gây stampede)
Giải pháp 1: Distributed lock (Redis SETNX)
Java (Spring Boot + Redisson)
Giải pháp 2: Request coalescing (Go singleflight)
Go implementation
Giải pháp 3: Cache pre‑warming & probabilistic TTL
Khi nào dùng circuit breaker?
Quy tắc thực tiễn (Rule of thumb)
Kết luận
Tóm tắt

Tình huống thực tế#

Bạn đang chuẩn bị cho đợt flash sale của một nền tảng thương mại điện tử. Khi đồng hồ đếm ngược tới 0, hàng ngàn người dùng cùng truy cập một API /product/{id} để lấy thông tin khuyến mãi. Độ trễ tăng đột biến, DB PostgreSQL bị quá tải và cuối cùng hệ thống sập.

Nguyên nhân: cache stampede là gì?#

Cache stampede xảy ra khi nhiều request đồng thời phát hiện một khóa cache (key) đã hết hạn và đồng thời đánh vào DB để tải lại dữ liệu. Nếu không có cơ chế kiểm soát, DB sẽ nhận một “cơn lốc” query – chính là nguyên nhân khiến flash sale sụp.

Tip: Cache stampede thường xuất hiện cùng với TTL ngắn (ví dụ 30s) và traffic cao (≥10k RPS).

Mô hình cache naïve (gây stampede)

Redis cache stampede trong flash sale – cách ngăn hệ thống sập · Pattern Quest

Java

@Service
public class ProductService {
    private final ProductRepository repo;
    private final RedisTemplate<String, ProductDto> redis;
    private static final String KEY_PREFIX = "product:";

    public ProductDto getProduct(Long id) {
        String key = KEY_PREFIX + id;
        // 1. Kiểm tra cache
        ProductDto cached = redis.opsForValue().get(key);
        if (cached != null) return cached;
        // 2. Cache miss → query DB
        ProductDto fresh = repo.findById(id)
                               .map(p -> new ProductDto(p))
                               .orElseThrow();
        // 3. Ghi lại cache (TTL 30s)
        redis.opsForValue().set(key, fresh, Duration.ofSeconds(30));
        return fresh;
    }
}

Java

@Service
public class ProductService {
    private final ProductRepository repo;
    private final RedissonClient redisson;
    private final RedisTemplate<String, ProductDto> redis;
    private static final String KEY_PREFIX = "product:";
    private static final String LOCK_PREFIX = "lock:product:";

    public ProductDto getProduct(Long id) {
        String key = KEY_PREFIX + id;
        String lockKey = LOCK_PREFIX + id;
        // 1. Try cache first
        ProductDto cached = redis.opsForValue().get(key);
        if (cached != null) return cached;

        // 2. Acquire distributed lock (wait max 100ms)
        RLock lock = redisson.getLock(lockKey);
        boolean acquired = lock.tryLock(100, 5, TimeUnit.SECONDS);
        if (!acquired) {
            // Another thread is loading, fallback to short wait & retry
            try { Thread.sleep(50); } catch (InterruptedException ignored) {}
            return redis.opsForValue().get(key); // may be fresh now
        }
        try {
            // Double‑check after acquiring lock
            cached = redis.opsForValue().get(key);
            if (cached != null) return cached;
            // 3. Load from DB
            ProductDto fresh = repo.findById(id)
                                   .map(p -> new ProductDto(p))
                                   .orElseThrow();
            // 4. Write cache
            redis.opsForValue().set(key, fresh, Duration.ofSeconds(30));
            return fresh;
        } finally {
            lock.unlock();
        }
    }
}

package service

import (
    "context"
    "time"
    "github.com/go-redis/redis/v8"
    "golang.org/x/sync/singleflight"
)

type Product struct{ ID int64; Name string; Price int64 }

var sf singleflight.Group
var rdb *redis.Client // init elsewhere

func GetProduct(ctx context.Context, id int64) (*Product, error) {
    key := fmt.Sprintf("product:%d", id)
    // 1. Try cache
    if data, err := rdb.Get(ctx, key).Result(); err == nil {
        var p Product
        if err := json.Unmarshal([]byte(data), &p); err == nil {
            return &p, nil
        }
    }
    // 2. Use singleflight to coalesce DB load
    v, err, _ := sf.Do(key, func() (interface{}, error) {
        // This block runs only once per key per burst
        p, err := loadFromDB(ctx, id)
        if err != nil { return nil, err }
        // Write cache (TTL 30s)
        bytes, _ := json.Marshal(p)
        rdb.Set(ctx, key, bytes, 30*time.Second)
        return p, nil
    })
    if err != nil { return nil, err }
    return v.(*Product), nil
}

func loadFromDB(ctx context.Context, id int64) (*Product, error) {
    // Simulate DB query
    time.Sleep(50 * time.Millisecond)
    return &Product{ID: id, Name: "Demo", Price: 1000}, nil
}

Real‑world scenario#

You are gearing up for a flash‑sale event on an e‑commerce platform. When the countdown hits zero, thousands of users hammer the endpoint /product/{id} to see the discounted price. Latency spikes, the PostgreSQL backend swells, and eventually the whole service crashes.

What is a cache stampede?#

A cache stampede happens when many concurrent requests notice that a cached entry has expired and all rush to the database to reload it. Without a throttling mechanism, the DB receives a sudden wave of identical queries – the classic cause of a flash‑sale outage.

Tip: Stampedes are common with short TTLs (e.g., 30 s) under high traffic (≥10k RPS).

Naïve caching (triggers stampede)#

Java

@Service
public class ProductService {
    private final ProductRepository repo;
    private final RedisTemplate<String, ProductDto> redis;
    private static final String KEY_PREFIX = "product:";

    public ProductDto getProduct(Long id) {
        String key = KEY_PREFIX + id;
        // 1. Check cache first
        ProductDto cached = redis.opsForValue().get(key);
        if (cached != null) return cached;
        // 2. Cache miss → hit DB
        ProductDto fresh = repo.findById(id)
                               .map(p -> new ProductDto(p))
                               .orElseThrow();
        // 3. Write back to cache (TTL 30s)
        redis.opsForValue().set(key, fresh, Duration.ofSeconds(30));
        return fresh;
    }
}

When the TTL expires, thousands of requests will simultaneously pass the if (cached != null) guard and immediately execute the DB query. The result is DB saturation, soaring latency, time‑outs, and often a circuit‑breaker trip.

Solution 1: Distributed lock (Redis SETNX)#

The classic remedy is a distributed lock that ensures only one request performs the expensive load while the rest wait or retry.

Java (Spring Boot + Redisson)#

Java

@Service
public class ProductService {
    private final ProductRepository repo;
    private final RedissonClient redisson;
    private final RedisTemplate<String, ProductDto> redis;
    private static final String KEY_PREFIX = "product:";
    private static final String LOCK_PREFIX = "lock:product:";

    public ProductDto getProduct(Long id) {
        String key = KEY_PREFIX + id;
        String lockKey = LOCK_PREFIX + id;
        // 1. Try cache first
        ProductDto cached = redis.opsForValue().get(key);
        if (cached != null) return cached;

        // 2. Acquire a distributed lock (max wait 100 ms)
        RLock lock = redisson.getLock(lockKey);
        boolean acquired = lock.tryLock(100, 5, TimeUnit.SECONDS);
        if (!acquired) {
            // Another thread is loading – short sleep then retry cache
            try { Thread.sleep(50); } catch (InterruptedException ignored) {}
            return redis.opsForValue().get(key); // may be fresh now
        }
        try {
            // Double‑check after acquiring lock
            cached = redis.opsForValue().get(key);
            if (cached != null) return cached;
            // 3. Load from DB
            ProductDto fresh = repo.findById(id)
                                   .map(p -> new ProductDto(p))
                                   .orElseThrow();
            // 4. Populate cache
            redis.opsForValue().set(key, fresh, Duration.ofSeconds(30));
            return fresh;
        } finally {
            lock.unlock();
        }
    }
}

Key points

tryLock uses a tiny wait window to avoid dead‑locks.
unlock is always in a finally block.
Lock TTL (5 s) is shorter than the typical DB query time, protecting the cache without causing long stalls.

Solution 2: Request coalescing with Go `singleflight`#

Go offers the golang.org/x/sync/singleflight package, which automatically merges duplicate calls for the same key into a single execution.

Go implementation#

package service

import (
    "context"
    "encoding/json"
    "fmt"
    "math/rand"
    "time"

    "github.com/go-redis/redis/v8"
    "golang.org/x/sync/singleflight"
)

type Product struct{ ID int64; Name string; Price int64 }

var sf singleflight.Group
var rdb *redis.Client // initialise elsewhere

func GetProduct(ctx context.Context, id int64) (*Product, error) {
    key := fmt.Sprintf("product:%d", id)
    // 1. Try cache first
    if data, err := rdb.Get(ctx, key).Result(); err == nil {
        var p Product
        if err := json.Unmarshal([]byte(data), &p); err == nil {
            return &p, nil
        }
    }
    // 2. Coalesce DB loads via singleflight
    v, err, _ := sf.Do(key, func() (interface{}, error) {
        // This block runs only once per burst
        p, err := loadFromDB(ctx, id)
        if err != nil { return nil, err }
        // Write cache with jittered TTL
        bytes, _ := json.Marshal(p)
        ttl := 30 + rand.Intn(5) // 30‑35 s
        rdb.Set(ctx, key, bytes, time.Duration(ttl)*time.Second)
        return p, nil
    })
    if err != nil { return nil, err }
    return v.(*Product), nil
}

func loadFromDB(ctx context.Context, id int64) (*Product, error) {
    // Simulated DB latency
    time.Sleep(50 * time.Millisecond)
    return &Product{ID: id, Name: "Demo", Price: 1000}, nil
}

singleflight.Group guarantees that only one DB query runs for the given key while other goroutines wait for the result, effectively eliminating the stampede.

Solution 3: Cache pre‑warming & probabilistic TTL#

If you know the flash‑sale window in advance, pre‑warm the hot keys by loading them into Redis before traffic spikes. Additionally, add a small random offset (jitter) to the TTL so that keys do not expire simultaneously.

Java

long ttl = 30 + ThreadLocalRandom.current().nextInt(5); // 30‑35 s
redis.opsForValue().set(key, fresh, Duration.ofSeconds(ttl));

ttl := 30 + rand.Intn(5) // seconds
rdb.Set(ctx, key, bytes, time.Duration(ttl)*time.Second)

These techniques dramatically lower the probability of a synchronized cache‑miss burst.

When to add a circuit breaker?#

Even with locks or singleflight, the downstream DB can still become a bottleneck (e.g., lock acquisition fails). A circuit breaker (Resilience4j, Hystrix) can protect your service by short‑circuiting calls and returning a graceful fallback (e.g., “product data is temporarily unavailable, please retry”).

Practical rule‑of‑thumb#

Never let a cache miss directly hit the DB under high‑traffic scenarios.
Use a distributed lock (Redisson) or singleflight to coalesce loads.
Add jitter to TTL to avoid simultaneous expirations.
Pre‑warm hot keys when you know the traffic burst ahead of time.
Pair the above with a circuit breaker for an extra safety net.

Conclusion#

Cache stampede is the invisible enemy of every flash‑sale. A few lines of lock or singleflight code can save an entire system. Apply the patterns to your ProductService today, measure latency before and after, and you’ll see the impact instantly.

Key takeaways#

Stampede = many requests miss the same cache key and flood the DB.
Fixes: distributed lock (Redisson), request coalescing (singleflight), jittered TTL, pre‑warming, circuit breaker.
Java example uses Redisson; Go example uses singleflight.
Always add jitter and consider a fallback strategy.

Have you ever been burned by a cache stampede during a sale? Share your story and the fix you chose in the comments!

Redis cache stampede trong flash sale – cách ngăn hệ thống sậpRedis cache stampede in flash sales – how to keep the system alive

Tình huống thực tế#

Nguyên nhân: cache stampede là gì?#

Mô hình cache naïve (gây stampede)

Redis cache stampede trong flash sale – cách ngăn hệ thống sậpRedis cache stampede in flash sales – how to keep the system alive

Tình huống thực tế#

Nguyên nhân: cache stampede là gì?#

Mô hình cache naïve (gây stampede)

Giải pháp 1: Distributed lock (Redis SETNX)#

Java (Spring Boot + Redisson)#

Giải pháp 2: Request coalescing (Go singleflight)#

Go implementation#

Giải pháp 3: Cache pre‑warming & probabilistic TTL#

Khi nào dùng circuit breaker?#

Quy tắc thực tiễn (Rule of thumb)#

Kết luận#

Tóm tắt#

Real‑world scenario#

What is a cache stampede?#

Naïve caching (triggers stampede)#

Solution 1: Distributed lock (Redis SETNX)#

Java (Spring Boot + Redisson)#

Solution 2: Request coalescing with Go `singleflight`#

Go implementation#

Solution 3: Cache pre‑warming & probabilistic TTL#

When to add a circuit breaker?#

Practical rule‑of‑thumb#

Conclusion#

Key takeaways#

Thảo luậnDiscussion

Tình huống thực tế#

Nguyên nhân: cache stampede là gì?#

Mô hình cache naïve (gây stampede)

Tình huống thực tế#

Nguyên nhân: cache stampede là gì?#

Mô hình cache naïve (gây stampede)

Giải pháp 1: Distributed lock (Redis SETNX)#

Java (Spring Boot + Redisson)#

Giải pháp 2: Request coalescing (Go singleflight)#

Go implementation#

Giải pháp 3: Cache pre‑warming & probabilistic TTL#

Khi nào dùng circuit breaker?#

Quy tắc thực tiễn (Rule of thumb)#

Kết luận#

Tóm tắt#

Real‑world scenario#

What is a cache stampede?#

Naïve caching (triggers stampede)#

Solution 1: Distributed lock (Redis SETNX)#

Java (Spring Boot + Redisson)#

Solution 2: Request coalescing with Go singleflight#

Go implementation#

Solution 3: Cache pre‑warming & probabilistic TTL#

When to add a circuit breaker?#

Practical rule‑of‑thumb#

Conclusion#

Key takeaways#

Bài học liên quanRelated lessons

Circuit Breaker

Thảo luậnDiscussion

Solution 1: Distributed lock (Redis SETNX)#

Java (Spring Boot + Redisson)#

Solution 2: Request coalescing with Go `singleflight`#

Solution 3: Cache pre‑warming & probabilistic TTL#