Performance Optimization of New‑User Group Order API Using Redis BitMap and StopWatch Profiling

Recently, after adding some risk control measures, the QPS and TPS of the new‑user group order API dropped by about 5%‑10%.

Business Overview: The “new‑user group” activity is initiated by a new user; if the group succeeds, the system automatically grants a coupon of ¥15 off a ¥15.1 purchase. Each user has only one chance, and the activity aims to attract new users.

Current Issue: To prevent abuse, the order risk‑control system was enhanced, adding synchronous calls that lengthened the order processing chain, causing the interface to miss performance targets.

Problem Analysis: The risk‑control checks consist of online synchronous analysis and offline asynchronous analysis. Strengthening the online rules increased the execution time, especially the step “determine whether the user is new”. This step queries the order database for a successful payment record, which is costly because the order table has tens of millions of rows and the user_id column is only indexed, not unique.

Solution Approach: Replace the database query with a Redis BitMap that records whether a user has a successful payment. The BitMap is set to true when a payment succeeds, and the order‑creation logic checks the BitMap instead of querying the database.

Code example for profiling with StopWatch :

@Transactional(rollbackFor = Exception.class)
public CollageOrderResponseVO colleageOrder(CollageOrderRequestVO request) {
    StopWatch stopWatch = new StopWatch();
    stopWatch.start("call risk control");
    // call risk control API
    stopWatch.stop();
    // other steps...
    stopWatch.prettyPrint();
    return new CollageOrderResponseVO();
}

After switching to the BitMap, the test‑environment execution time dropped from ~1.2 s to ~0.82 s, a 31 % reduction, with the “determine new user” step now taking only ~1.8 % of the total time.

Incident: In production, user IDs grew from 8‑digit to 18‑digit values, causing the BitMap offset to exceed Redis’s 512 MiB limit (2³² bytes). This triggered a RedisCommandExecutionException: ERR bit offset is not an integer or out of range and the gray‑release failed.

Lessons Learned:

Technical solutions must be aligned with business data characteristics.

Pre‑production environments that mirror real data are essential for catching such issues.

Maintain a healthy respect for the limits of underlying systems.