An S3 lock needs a plan for the worker that returns late
S3 conditional creation can choose a lock winner. Safe leader election also needs expiry rules, stale-worker rejection and a clear side-effect boundary.
By 
Paul. Architecture and infrastructure
Winning a lock and remaining entitled to perform work are different events. S3 conditional creation can settle a competition to create an object, but it cannot by itself stop an old worker from waking up and completing a harmful action. A leader-election design needs an answer at the resource being protected, as well as at the lock.
This November 2026 retrospective examines the August 2024 primitive and the leader-election proposal it prompted. The distinction matters when a team tries to avoid adding a coordination service: fewer services can reduce operating work, but the remaining application still has to enforce its failure rules.
The August primitive had a specific scope
AWS's 20 August 2024 announcement introduced conditional writes that check whether an object exists before creating it. It names PutObject and CompleteMultipartUpload and the If-None-Match header. Conditional creation moves the existence check into the storage operation instead of relying on a separate client-side check followed by a write.
ETag-based conditional updates belong to a later event. AWS's 25 November 2024 announcement describes If-Match checks against an object's ETag for those write operations. Importing that later facility into an explanation of the August algorithm would change the primitive being evaluated.
The distinction affects the lock representation. A design based on creating a previously absent object must not casually assume it can also compare and replace an existing record. Both are conditional writes in ordinary language, yet they support different state transitions.
Follow ownership through an epoch
In his 26 August 2024 proposal, Gunnar Morling describes creating a new lock object for each leader epoch. Contenders list the lock objects, identify the latest epoch and attempt conditional creation of the next one. Only the successful creator wins that epoch. The article separately discusses voluntary expiry, time-limited validity and fencing off stale workers.
Keeping epochs separate is important to that reasoning. The object key records a leadership generation rather than inviting every contender to overwrite one shared claim. A failed contender must reconsider the state; losing the creation race is not permission to continue with the protected work.
The proposal is useful material for analysis, rather than proof that an arbitrary implementation is correct. Permissions, cleanup and every other writer must preserve its assumptions. A normal unconditional write by another path can undermine a protocol whose correctness argument assumes all contenders use conditional creation.
Recovery introduces the difficult case
Consider a proposed export service in which only one worker should publish a customer-facing manifest. Worker A acquires an epoch and begins preparing the export. It then pauses for longer than the validity period. Worker B treats the lease as expired, acquires the next epoch and publishes a newer result. A resumes with its old work still in memory.
That is an illustrative failure sequence, not an observed S3 incident. It exposes what expiry means. Allowing B to make progress solves the problem of waiting forever for A. It does not erase A's ability to send a delayed request. Checking ownership immediately before writing also leaves a gap if the process pauses between the check and the effect.
A fencing design carries an ownership generation to the protected resource. That resource must reject actions from an older generation after accepting the newer one, with the check bound to the consequential operation. Merely attaching an epoch to a log entry is insufficient. The recipient must enforce the rule, and the implementation must establish that generation values and comparisons are reliable.
If the destination is an external API that cannot reject stale generations, the lock protocol cannot create that capability on its behalf. The design may need a different boundary, such as an enforceable publication record or a destination-supported deduplication rule. Deduplication and fencing address different failures: repeating the same action is different from an old owner performing a conflicting action.
Timing and uncertainty remain part of the contract
A lease introduces assumptions about time and pauses. State which clock is used, how uncertainty is handled and when a worker must stop. Morling discusses clock differences and requests that can complete after a lock is no longer valid. Treat those discussions as requirements to examine, rather than turning a timeout value into a correctness guarantee.
A request timeout is also ambiguous. The caller may not know whether conditional creation succeeded. Blindly treating every timeout as a definite loss, or as a definite win, can produce the wrong next action. The implementation needs a way to reconcile the outcome using its recorded identity and current state.
Proposed review cases should include pausing an owner past expiry, delaying a response and retrying after an uncertain result. Follow the effect all the way to the protected resource. No such implementation or failure exercise was executed for this article. A convincing diagram or a successful uncontended run would not establish the missing failure behaviour.
Another service can be the simpler system
The strongest counterargument to building coordination on S3 is that a dedicated coordination service, or a suitable facility in an already-operated database, can make the design easier to understand. Maintaining a bespoke protocol may cost more than operating the additional dependency. A service count is a poor proxy for total complexity.
The S3 approach remains worth considering when the work and its enforceable ownership boundary already live in object storage. It is less persuasive when leadership must govern unrelated destinations that cannot enforce the chosen generation. Evaluate the entire path instead of judging the lock object alone.
For a custom software project, require the design to explain what happens when the former owner returns late. Identify which resource rejects it and how recovery preserves progress. Conditional creation is a useful building block. The application earns its correctness argument by connecting that building block to every consequential effect.