Summary
DynamoDB conditional writes (ConditionExpression) enable distributed leader election by implementing compare-and-swap: only the first writer to claim a leadership token succeeds; concurrent claimants fail with ConditionalCheckFailedException, ensuring exactly one leader is elected.
Evidence
- ·{'DynamoDB conditional write': 'attribute_not_exists(leader) ensures only one writer succeeds on empty token'}
- ·DynamoDB TTL on leadership record enables automatic lease expiry: dead leaders release the token within TTL window
- ·AWS DynamoDB documentation explicitly documents leader election as a conditional writes use case
- ·Amazon SWF (Simple Workflow) uses DynamoDB conditional writes internally for distributed task assignment
- ·The amazon-dynamodb-lock-client library implements distributed lock (and thus leader election) using conditional writes
Operational Context
- ·Lease TTL must exceed the maximum expected leader heartbeat interval: tune for your failover latency requirement
- ·Leader must renew its lease before TTL expiry using a conditional write that checks its own token
- ·Lease renewal failures (network partition) cause the leader to step down: prevents zombie leaders
Tradeoffs
- ·DynamoDB TTL expiry has a 48-hour SLA (not instant): a dead leader's token may persist after TTL in rare cases
- ·Conditional write failure rate under contention is directly proportional to the number of candidates
- ·DynamoDB leader election adds external dependency on DynamoDB availability for all coordination operations
Evidence grounding
Grounded, 5 supporting itemsDynamoDB conditional writes for leader election is a documented pattern used in AWS Lambda, AWS SDK distributed lock implementations, and serverless coordination use cases.