Kurly Resolves Concurrency Issues in Inbound Service with Redisson-Based Distributed Locks

Kurly's Fulfillment Product team introduced distributed locks based on Redisson to solve concurrency issues occurring in the inbound service (RMS). This was to prevent incorrect inventory transactions from being created due to causes such as duplicate order receipt via Kafka, double-clicking during inspection, or simultaneous clicks by multiple workers during transfer shipment.

With the existing Application exception handling, a common lock could not be applied in a multi-instance environment, and Redis was chosen because it could leverage the team's existing tech stack and, compared to MySQL, reduces the burden of connection pool management, thereby lowering the load on RDS. In particular, Redisson was chosen over Lettuce because its support for the Lock interface makes timeout configuration easy, and because it minimizes Redis load by receiving lock-release signals through a Pub/Sub method rather than a spinlock approach.

Distributed Lock Component Design and Implementation

To prevent business logic contamination, the distributed lock logic was implemented separately based on AOP (Aspect-Oriented Programming). Through the @DistributedLock annotation, values such as key, waitTime, and leaseTime can be custom-specified, and Spring Expression Language (SpEL) is used to dynamically generate lock names.

The core implementation point is releasing the lock after the transaction commit. By applying @Transactional(propagation = Propagation.REQUIRES_NEW) to the AopForTransaction class, the logic executed after lock acquisition operates as an independent transaction, and the design ensures the lock is released only after the transaction commit is complete. This blocks consistency errors that occur when the lock is released but the data has not yet been reflected in the DB.

Concurrency Verification Test Results

The effectiveness of the distributed lock was verified through coupon issuance and duplicate order registration scenarios. In a test where 100 customers simultaneously requested issuance of 100 coupons, without the distributed lock applied, the remaining coupon count was 79, breaking data consistency. In contrast, when the distributed lock was applied, exactly 100 were deducted, recording 0 remaining and confirming normal processing.

Also, in a scenario where 10 duplicate order records were received simultaneously, applying the distributed lock blocked duplicates through existsByCode validation, ensuring that only 1 record was registered. This significantly improved the data accuracy and system stability of the inbound service.