Prevent Overselling in Group‑Buy Flash Sales: Redis Locks, MQ Timers & Reliable Messaging

Scenario: 100 Users Compete for One Seat

Imagine a popular product group‑buy where only one spot remains and 100 users click "Join Group" at the same second. In a naïve system, all requests flood the database, each checking the remaining quota and decrementing it, leading to massive overselling, database lock contention, and service crash.

Core Challenge 1: Concurrency Control – Redis Lock as Ticket Inspector

Wrong approach – Database pessimistic lock

Using SELECT ... FOR UPDATE locks the row for the first request while the other 99 wait, causing request blockage and performance collapse under high load.

Correct approach – Redis distributed lock

Employ Redis as a fast in‑memory ticket inspector. By using the atomic SETNX command to create a lock key, only one request obtains the lock and proceeds to the database, while the others receive a “seat full” response or enter a short wait queue. This keeps the critical section in memory, protecting the database from overload.

Core Challenge 2: Timeout Handling – MQ Delayed Messages as Smart Alarms

When a group‑buy is created but not filled within 24 hours, the system must detect the timeout and refund paid users.

Inefficient solution – Periodic polling task

A scheduled job scans all “group‑buying” orders every minute. This full‑table scan works for low volume but devastates the database at large scale.

Elegant solution – Message‑queue delayed messages

When a group‑buy is created, a delayed MQ message (e.g., 24 hours later) is sent. The system can forget about the order until the message arrives, then checks the order status and triggers a refund if still pending, eliminating continuous DB pressure.

Core Challenge 3: Reliable Notification – Outbox (Local Message Table) Pattern

Refund notifications to the payment service must be guaranteed even if the network or payment service is temporarily unavailable.

Problem with direct RPC/HTTP calls

Assuming the network is always reliable leads to lost notifications.

Reliable solution – Local message table

Within the same transaction that updates the order status to “refunded”, insert a record into a local message table describing the notification. A separate background worker scans this table, attempts to call the payment service, and marks the message as sent only on success, retrying automatically on failure.

Final Architecture: Building a Robust Group‑Buy Service

The combined solution consists of:

Redis “ticket inspector” for distributed locking at the entry point.

MQ “smart alarm” for delayed timeout handling.

Outbox (local message table) for reliable cross‑service notifications.

A state machine managing order transitions from “group‑buying” to “success” or “failure”.

Persistent storage of final states in the database.

Together, these techniques create a high‑availability, fault‑tolerant group‑buy system capable of handling massive concurrent traffic without overselling or data loss.