---
title: Distributed Locking, Redlock, and Consistent Hashing on AWS
description: Redlock debates matter because ElastiCache is not a consensus system. Consistent hashing for sharding workers and ALB target stickiness, with DynamoDB conditional writes as the simpler alternative.
url: https://www.joinhorizon.co/blog/distributed-coordination-redlock-consistent-hashing-elasticache/
datePublished: 2026-06-12T00:00:00.000Z
dateModified: 2026-10-28T00:00:00.000Z
author: palaniappan-p
category: Cloud Architecture
tags: engineering-guide, distributed-systems, elasticache, aws
---

# Distributed Locking, Redlock, and Consistent Hashing on AWS

> Redlock debates matter because ElastiCache is not a consensus system. Consistent hashing for sharding workers and ALB target stickiness, with DynamoDB conditional writes as the simpler alternative.

Martin Kleppmann’s critique still holds as of June 2026: Redis-based Redlock does not provide the same guarantees as Raft, and clock skew and TTL expiry create false confidence.

## Symptoms, mechanisms, and AWS controls

| Production symptom                  | Mechanism                    | AWS control                                                  |
| ----------------------------------- | ---------------------------- | ------------------------------------------------------------ |
| Double booking under partition      | Redlock lacks fencing tokens | DynamoDB conditional PutItem with lease TTL                  |
| Hot key on lock shard               | Consistent hashing skew      | ElastiCache Serverless auto-sharding, key-space partitioning |
| Lock holder crashes without release | TTL-based lease expiry       | SQS visibility timeout pattern as lock alternative           |

My recommendation: skip Redlock for production inventory. Use DynamoDB conditional leases or SQS single-consumer patterns unless you have fencing tokens wired end to end.

> **Benchmark pattern (hypothetical workload):** inventory reservation service using DynamoDB conditional locks vs a Redis lock on a 3-node ElastiCache cluster (not true Redlock, which needs independent masters), 5K lock acquisitions/sec, Redlock false-positive releases at 0.02% under 200ms network partition vs 0% with DynamoDB lease table.

## AWS-aligned coordination

| Need            | Prefer                                           | Avoid                                      |
| --------------- | ------------------------------------------------ | ------------------------------------------ |
| Mutex           | DynamoDB conditional update with lease attribute | Redis lock across ElastiCache primary/replica (replication is async) |
| Leader election | ECS/EKS lease + DynamoDB lock item               | Infinite TTL without fencing token         |
| Work routing    | Consistent hash ring with virtual nodes          | Random assign breaking cache locality      |

Consistent hashing minimizes remapping when nodes change. Use it for worker pools, Kafka partition keys, and ALB sticky sessions (with failover caveats).

## ElastiCache locking

If you must use Redis locks, use a short TTL, pass fencing tokens downstream (a DB version check), and monitor `WAIT` latency.

## AWS services map

| Need                                | Service                        | Skip when                                 |
| ----------------------------------- | ------------------------------ | ----------------------------------------- |
| Fencing-token-safe distributed lock | DynamoDB conditional writes    | Single-instance PostgreSQL advisory locks |
| Session affinity routing            | ElastiCache consistent hashing | Stateless Lambda with no shared state     |
| Leader election                     | SQS FIFO + single consumer     | Kubernetes Lease API on EKS suffices      |

## What to do this week

1. Replace `SETNX` cron leader with DynamoDB `LockID` conditional put.
2. Document hash ring behavior on worker scale events.
3. Load test lock holder crash during write.

## More in this track

Part of the **Engineering Guides** library (June 2026).

- Previous: [Part 2](https://www.joinhorizon.co/blog/crdts-eventual-consistency-anti-patterns-aws/)
- Next: [Part 4](https://www.joinhorizon.co/blog/consensus-paxos-raft-byzantine-fault-tolerance-cloud/)
- Browse tracks: [Engineering Guides hub](https://www.joinhorizon.co/resources/engineering-guides/)

## What this guide doesn't cover

Paxos/Raft theory is in the next guide in the track.

## FAQ

### When should I not use Redlock on ElastiCache?
Skip Redlock for inventory and anything that needs fencing. Kleppmann’s critique still holds in June 2026: clock skew and TTL expiry create false confidence. Prefer DynamoDB conditional PutItem with a lease TTL, or SQS visibility timeout as a lock alternative.

### What is a fencing token and why does Redis SETNX lack one?
A fencing token is a monotonically increasing lease the resource itself checks. SETNX plus TTL can expire while a holder is still writing. Pass a DynamoDB version into downstream writes so a stale lock cannot commit.

### When is consistent hashing the right tool versus a lock?
Use hashing to route work (workers, Kafka keys, ALB stickiness) so remapping stays small when nodes change. Do not use a hash ring as a mutex. Hot lock shards need key-space partitioning or ElastiCache Serverless, not a tighter TTL.

### Can PostgreSQL advisory locks replace DynamoDB leases?
Only on a single instance. Multi-node or multi-Region coordination still wants DynamoDB conditional writes or a Kubernetes Lease on EKS. Advisory locks do not fence across failovers the way a versioned item does.

---

*Source: https://www.joinhorizon.co/blog/distributed-coordination-redlock-consistent-hashing-elasticache/*