Optimizing New User Group Buying Order Interface with Redis Bitmap and StopWatch Profiling

Introduction

Recently, additional risk‑control measures caused the QPS and TPS of the new‑user group‑buying order interface to drop by about 5%–10%. The activity, initiated by a new user, rewards a coupon when the group purchase succeeds and is primarily used for user acquisition.

Problem Analysis

The risk‑control system performs both online synchronous analysis and offline asynchronous analysis. Strengthening the online rules lengthened the execution chain of the order interface, leading to the observed performance degradation.

Solution Idea

Simply adding more servers is not a sustainable solution. Instead, the team used StopWatch to profile the method, revealing that the "determine if new user" step consumed the most time.

<span>@Transactional</span>(rollbackFor = Exception.class)</code><code>public CollageOrderResponseVO colleageOrder(CollageOrderRequestVO request) {</code><code>    StopWatch stopWatch = new StopWatch();</code><code>    stopWatch.start("调用风控系统接口");</code><code>    // call risk‑control service</code><code>    stopWatch.stop();</code><code>    stopWatch.start("获取拼团活动信息");</code><code>    // fetch activity info from cache</code><code>    stopWatch.stop();</code><code>    stopWatch.start("获取用户基本信息");</code><code>    // fetch user info via HTTP</code><code>    stopWatch.stop();</code><code>    stopWatch.start("判断是否是新用户");</code><code>    // query order DB to check payment success</code><code>    stopWatch.stop();</code><code>    stopWatch.start("生成订单并入库");</code><code>    // create order and persist</code><code>    stopWatch.stop();</code><code>    stopWatch.prettyPrint();</code><code>    return new CollageOrderResponseVO();</code><code>}

Proposed Optimization

Since the only needed information is whether the user has a successful payment, the team replaced the DB query with a Redis bitmap flag set at payment success time.

// key represents whether a user has a successful payment order</code><code>// userId is a long</code><code>String key = "order:f:paysucc";</code><code>redisTemplate.opsForValue().setBit(key, userId, true);

During order processing, the check becomes:

Boolean paySuccFlag = redisTemplate.opsForValue().getBit(key, userId);</code><code>if (paySuccFlag != null && paySuccFlag) {</code><code>    // not a new user, reject</code><code>}

Results

After the change, profiling showed the total execution time reduced to ~0.82 s (31% faster). The remaining bottleneck is the order insertion step.

StopWatch '新人拼团订单StopWatch': running time = 82207200 ns</code><code>---------------------------------------------</code><code>ns         %     Task name</code><code>---------------------------------------------</code><code>014113100  017%  调用风控系统接口</code><code>010193800  012%  获取拼团活动信息</code><code>013965900  017%  获取用户基本信息</code><code>014532800  018%  判断是否是新用户</code><code>029401600  036%  生成订单并入库

Production Incident

In production, the bitmap approach failed with ERR bit offset is not an integer or out of range because new user IDs grew from 8‑digit to 18‑digit values, exceeding Redis's 512 MiB string limit (2^32 bytes).

Lessons Learned

Technical solutions must be aligned with business constraints; understanding ID generation rules is crucial.

A pre‑production environment that mirrors real data can surface such issues early.

Respect the design intent behind existing code and parameters to avoid hidden risks.

Conclusion

The optimization significantly improved interface performance but also highlighted the need for additional servers for pre‑production testing and reinforced the importance of holistic system awareness.