Backend Development 8 min read

Implementing a High‑Concurrency Flash‑Sale System with Spring Boot and Redis List Queue

This article explains why common Redis‑based flash‑sale demos using WATCH or distributed locks are unreliable, and presents a simple, atomic solution that leverages Spring Boot's StringRedisTemplate with Redis list operations (LPUSH/RPOP) to achieve high‑concurrency秒杀 without explicit locking.

Top Architect
Top Architect
Top Architect
Implementing a High‑Concurrency Flash‑Sale System with Spring Boot and Redis List Queue

The author needs a flash‑sale (秒杀) system where 100 users compete to grab limited items, and finds most Java demos that rely on Redis WATCH transactions or distributed locks either lack retry mechanisms or cause severe performance degradation under high concurrency.

Three flawed approaches are discussed:

Using Redis WATCH as an optimistic lock – many users fail, and demos often omit retry logic, leading to poor user experience.

Implementing a Redis‑based distributed lock with SETNX – only one client obtains the lock, and without retries the rest immediately fail.

Relying on Lua or other scripts – hard to understand and maintain for many developers.

To overcome these issues, the author proposes a straightforward method that treats the inventory as a Redis list. By pre‑loading the list with one entry per item (LPUSH) and letting each request atomically pop an element from the right (RPOP), the system naturally enforces first‑come‑first‑served semantics without explicit locking.

The core service is implemented with Spring Boot's StringRedisTemplate :

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;
import java.time.Duration;
import java.util.Collection;

@Service
public class RedisServiceImpl
implements RedisService
{
    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    // add a string with expiration
    @Override
    public void addString(String key, String value, Duration duration) {
        stringRedisTemplate.opsForValue().set(key, value, duration);
    }

    // find a string
    @Override
    public String findString(String key) {
        return stringRedisTemplate.opsForValue().get(key);
    }

    // delete by key
    @Override
    public Boolean deleteByKey(String key) {
        return stringRedisTemplate.delete(key);
    }

    // pop one element from the right of a list (consume)
    @Override
    public String removeOneEntryOnListRight(String listName) {
        return stringRedisTemplate.opsForList().rightPop(listName);
    }

    // push a collection of elements to the left of a list (produce)
    @Override
    public Long addEntriesOnListLeft(String listName, Collection
args) {
        return stringRedisTemplate.opsForList().leftPushAll(listName, args);
    }
}

Usage example – initializing the inventory queue:

List
entriesList = new LinkedList<>();
for (int i = 0; i < 100; i++) {
    entriesList.add("某个商品");
}
redisService.addEntriesOnListLeft("queueName", entriesList);

Processing each flash‑sale request:

String redisResult = redisService.removeOneEntryOnListRight("queueName");
if (redisResult == null) {
    // not successful
} else {
    // successful – execute business logic for the grabbed item
}

This approach eliminates concurrency problems because Redis processes commands sequentially, guaranteeing atomicity. It also scales easily: adding more items or clearing the queue only requires LPUSH or DEL commands, without code changes. The author notes that even with 100 000 items the memory footprint remains modest.

Finally, the article includes promotional messages and links, but the technical core provides a practical, production‑ready pattern for high‑throughput flash‑sale scenarios.

backendJavaConcurrencyRedisSpring Bootflash sale
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.