Ever since I watched two microservices trip over each other trying to update the same inventory record, I’ve been obsessed with distributed locking. That moment when simultaneous requests created phantom stock levels taught me a hard lesson: in distributed systems, good intentions aren’t enough. You need enforceable coordination. Today I’ll share how Redis and Spring Boot can prevent such race conditions, drawing from production-tested patterns I’ve implemented across financial and e-commerce systems.

Getting started requires minimal setup. First, include these dependencies in your Spring Boot project:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson-spring-boot-starter</artifactId>
    <version>3.24.3</version>
</dependency>

Configure Redis in application.yml:

spring:
  redis:
    host: localhost
    port: 6379
redisson:
  single-server-config:
    address: "redis://localhost:6379"

Now, the core locking mechanism. Why use Lua scripts? Because they execute atomically - critical when multiple services compete for the same lock. Here’s our fundamental lock interface:

public interface DistributedLock {
    boolean tryLock(String lockKey, String lockValue, long expireTime);
    boolean unlock(String lockKey, String lockValue);
}

The concrete implementation uses Redis’ atomic operations:

@Component
public class RedisLock implements DistributedLock {
    private final StringRedisTemplate redisTemplate;
    
    private static final String LOCK_SCRIPT = 
        "if redis.call('setnx', KEYS[1], ARGV[1]) == 1 then " +
        "   redis.call('pexpire', KEYS[1], ARGV[2]); " +
        "   return 1; " +
        "else " +
        "   return 0; " +
        "end";
    
    public boolean tryLock(String lockKey, String value, long expireMs) {
        return redisTemplate.execute(
            new DefaultRedisScript<>(LOCK_SCRIPT, Long.class),
            List.of(lockKey), value, String.valueOf(expireMs)
        ) == 1;
    }
}

Notice the lockValue parameter? It uniquely identifies the lock holder. This prevents service A from accidentally releasing service B’s lock. But what happens if our service crashes before releasing?

Lock expiration is our safety net. I set TTLs conservatively - long enough to complete operations but short enough to prevent prolonged deadlocks. For critical processes like payment handling, I add renewal mechanisms:

@Scheduled(fixedDelay = 5000)
public void renewLocks() {
    activeLocks.forEach((lockKey, lockValue) -> {
        if (!redisTemplate.expire(lockKey, Duration.ofSeconds(30))) {
            logger.warn("Failed to renew lock {}", lockKey);
        }
    });
}

Spring Boot integration shines with annotation-based locking. Ever wish you could just @Lock a method? We can build that:

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface DistributedLock {
    String key();
    long timeoutMs() default 3000;
}

The aspect handles acquisition and release:

@Aspect
@Component
public class LockAspect {
    @Autowired
    private DistributedLock lockService;
    
    @Around("@annotation(lockAnnotation)")
    public Object applyLock(ProceedingJoinPoint joinPoint, DistributedLock lockAnnotation) throws Throwable {
        String lockKey = lockAnnotation.key();
        String lockValue = UUID.randomUUID().toString();
        
        if (!lockService.tryLock(lockKey, lockValue, lockAnnotation.timeoutMs())) {
            throw new LockAcquisitionException("Failed to acquire lock for " + lockKey);
        }
        
        try {
            return joinPoint.proceed();
        } finally {
            lockService.unlock(lockKey, lockValue);
        }
    }
}

Now secure any method with:

@DistributedLock(key = "order_#{orderId}")
public void processOrder(String orderId) {
    // Critical section
}

But how do we know it’s working? Monitoring is non-negotiable. I expose lock metrics via Spring Actuator:

@Bean
public MeterBinder lockMetrics(DistributedLock lock) {
    return registry -> Gauge.builder("distributed.lock.waiting", lock::getWaitingThreads)
                            .register(registry);
}

For high-throughput systems, I optimize with local lock caching. Before hitting Redis, services first check a thread-safe local map. This reduces network calls for frequently contested resources.

Common pitfalls? I’ve learned these lessons the hard way:

• Always set TTLs - infinite locks become infinite headaches
• Verify lock ownership before release - scripted operations prevent accidental unlocks
• Test failure scenarios - what happens when Redis goes down?

Redisson offers production-ready alternatives if you need advanced features like reentrant locks. Their RLock implementation handles complex scenarios out-of-the-box.

Distributed locking transformed how my teams handle shared resources. From preventing duplicate cron jobs to maintaining financial transaction integrity, these patterns deliver consistency where it matters most. What race conditions keep you up at night? Share your experiences below - I read every comment. If this solved a problem for you, pay it forward by sharing with your network.