Distributed Locking, Redlock, and Consistent Hashing on AWS
Quick summary: 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 boring alternative.
Key Takeaways
- Consistent hashing for sharding workers and ALB target stickiness—with DynamoDB conditional writes as the boring alternative
- Martin Kleppmann’s critique (still valid June 2026): Redis-based Redlock does not provide the same guarantees as Raft—clock skew and TTL expiry create false confidence
- What to do this week 1
- Replace cron leader with DynamoDB conditional put
- 2
Table of Contents
Martin Kleppmann’s critique (still valid June 2026): Redis-based Redlock does not provide the same guarantees as Raft—clock skew and TTL expiry create false confidence.
AWS-aligned coordination
| Need | Prefer | Avoid |
|---|---|---|
| Mutex | DynamoDB conditional update with lease attribute | Redlock across ElastiCache primary/replica |
| Leader election | ECS/EKS lease + DynamoDB lock item | Infinite TTL without fencing token |
| Work routing | Consistent hash on hash(user_id) % N | Random assign breaking cache locality |
Consistent hashing minimizes remapping when nodes change—use for worker pools, Kafka partition keys, ALB sticky sessions (with failover caveats).
ElastiCache locking
If you must use Redis locks: short TTL, fencing tokens passed to downstream (DB version check), monitor WAIT latency.
What to do this week
- Replace
SETNXcron leader with DynamoDBLockIDconditional put. - Document hash ring behavior on worker scale events.
- Load test lock holder crash during write.
What this guide doesn’t cover
Paxos/Raft theory—next guide in track.
AWS Cloud Architect & AI Expert
AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.
