The predicate is the whole trick. Selection happens by age, not by offset or cursor: at the start of a run you record the retention policy and a timestamp meaning older than this cutoff, then take a bounded page, process it, and commit before acknowledging the work item [6]. A second delivery therefore re-selects a subset of what the first one saw, and the operation key already committed for those rows turns the repeat into a no-op [19]. A missed or paused trigger needs no catch-up path either, because the next run's age predicate covers the gap [7]. The author calls the second delivery "deliberately boring" [22], which is the correct ambition for anything holding a DELETE.
The 900-second run ceiling is presented as a reason to leave margin, not a runtime objective [8][9]. Divide by 60 and that ceiling is fifteen minutes [23]. It is long enough that a run using its whole budget can overlap the next fire of any tighter schedule, and overlap is survivable here only because of the recorded cutoff and the key [6][19]. That ordering is why the piece says to write the ledger before enabling the delete [25]. The invariant has to exist before the thing that leans on it.
The prose and the sample disagree about what the key covers. The write-up describes a practical key as the policy version, the recorded cutoff, and the record IDs in the batch, stored with the deletion or audit write inside the same transaction [19]. The Go model hashes the policy, the cutoff, and a single record ID [20]. Per-record keys are the more forgiving choice, because a batch that dies halfway resumes and re-commits only the rows it never reached. A batch-scoped key needs reproducible batch composition, and the sample composes a batch by collecting IDs older than the cutoff, sorting them, and cutting at a limit [21], which is composition that moves as other writers add and remove rows. Lift the sample and you get per-record semantics; implement the paragraph and you get the other ones [24].
The visibility timeout is the edge that actually cuts. It must exceed the worker's expected processing interval, or an unacknowledged message can become visible while the first worker is still mutating rows, behaviour the piece attributes to AWS's visibility-timeout guidance [13]. Notice what that does to the idempotency argument. Duplicate-after-crash is a sequential test. Two workers inside the same age window is a concurrent one, and a rate-limited dependency makes it likelier, since honouring Retry-After stretches processing time while the timeout stays wherever you set it [12].
For the direct sweep to be sufficient, the selection has to be bounded, the delete has to be safe to repeat, and the runtime margin has to be comfortable [15]. The word carrying the weight is "demonstrably": bounded means you measured the candidate set, not that it was small last quarter. Queued batches earn their keep when units need independent retries, when a rate-limited dependency sets throughput, or when several workers drain a backlog [16], and they bill you in visibility timeouts, backlog monitoring, poison-message handling, and deployment coordination [18]. Above that sits a control plane you do not need for a single age-based sweep; that one arrives with dependencies, branching, joins, or approvals [17]. Component count is the cheaper scoreboard. Recovery of one unit is the one the design is built to protect [18].
