How to Prevent Duplicate Submissions in Java APIs with Redis and Redisson

Preface

As an experienced Java backend developer, I have built many management back‑ends and mini‑programs. I have never suffered data loss due to code crashes because I follow strict coding standards, use simple business logic and accumulated practical techniques.

What is Debounce?

Debounce means preventing user “hand shaking” and network jitter. In web systems, repeated form submissions caused by accidental clicks or network delays can create duplicate records. Front‑end usually shows a loading state, but back‑end must also implement debounce logic to reject duplicate requests.

An ideal debounce component should be:

Logically correct, without false positives.

Fast response.

Easy to integrate and decoupled from business logic.

Provide clear user feedback, e.g., “You are clicking too fast”.

Thought Process

Not every API needs debounce. Typically required for:

User‑input APIs such as search or form fields.

Button‑click APIs like submit or save.

Scroll‑load APIs such as pull‑to‑refresh or infinite scroll.

How to Determine Duplicate Requests?

Duplicate detection can be based on a time window, comparison of key parameters, and optionally the request URL.

Debounce in Distributed Deployment

Solution 1: Shared Cache

Use a shared Redis key with an expiration time. The flow diagram is shown below.

Solution 2: Distributed Lock

Use Redis SET_IF_ABSENT or Redisson lock to acquire a lock per request. The flow diagram is shown below.

Common distributed components are Redis and Zookeeper, but Redis is usually preferred because it is already part of most web stacks.

Implementation

Example controller method:

@PostMapping("/add")
@RequiresPermissions("add")
@Log(methodDesc="添加用户")
public ResponseEntity<String> add(@RequestBody AddReq addReq) {
    return userService.add(addReq);
}

Request DTO:

package com.summo.demo.model.request;
import java.util.List;
import lombok.Data;
@Data
public class AddReq {
    private String userName;
    private String userPhone;
    private List<Long> roleIdList;
}

Without a unique index on userPhone, each call creates a new user even if the phone number is the same.

RequestLock Annotation

Define @RequestLock with prefix, expire, timeUnit, delimiter, etc., and place it on the controller method.

Generating a Unique Key

Use @RequestKeyParam on method parameters or fields to compose the lock key. The generator reflects annotated fields and builds a key like “prefix&userName&userPhone”.

public class RequestKeyGenerator {
    public static String getLockKey(ProceedingJoinPoint joinPoint) {
        // ... (logic omitted for brevity)
        return requestLock.prefix() + sb;
    }
}

Redis Cache Implementation

Aspect intercepts the method, builds the lock key, and executes SET_IF_ABSENT with expiration via StringRedisTemplate.

@Around("execution(public * * (..)) && @annotation(com.summo.demo.config.requestlock.RequestLock)")
public Object interceptor(ProceedingJoinPoint joinPoint) {
    // ... (logic omitted)
    Boolean success = stringRedisTemplate.execute(connection ->
        connection.set(lockKey.getBytes(), new byte[0],
            Expiration.from(requestLock.expire(), requestLock.timeUnit()),
            RedisStringCommands.SetOption.SET_IF_ABSENT));
    if (!success) {
        throw new BizException(ResponseCodeEnum.BIZ_CHECK_FAIL, "Your operation is too fast, please try later");
    }
    return joinPoint.proceed();
}

Redisson Distributed Lock

Similar aspect uses RedissonClient to acquire a lock, set expiration, execute the method, and finally release the lock.

@Around("execution(public * * (..)) && @annotation(com.summo.demo.config.requestlock.RequestLock)")
public Object interceptor(ProceedingJoinPoint joinPoint) {
    // ... (logic omitted)
    RLock lock = redissonClient.getLock(lockKey);
    if (!lock.tryLock()) {
        throw new BizException(ResponseCodeEnum.BIZ_CHECK_FAIL, "Your operation is too fast, please try later");
    }
    lock.lock(requestLock.expire(), requestLock.timeUnit());
    try {
        return joinPoint.proceed();
    } finally {
        if (lock.isHeldByCurrentThread()) {
            lock.unlock();
        }
    }
}

Testing Results

First submission: “Add user success”.

Rapid repeat: “BIZ-0001: Your operation is too fast, please try later”.

After lock expires: “Add user success”.

Debounce works, but once the cache expires or the lock is released, duplicate requests can still occur. True idempotency also requires business‑level checks and database unique constraints.