The Queue Was a Table: How I Built Claim/Unclaim Workers with SKIP LOCKED, Stale Recovery, and Retry Caps

I noticed a weird pattern in the reminders pipeline: the same work would go quiet for a while, then show up again later—like a sticky note that fell behind the desk and got kicked back out. Nothing was actually disappearing. The work was getting claimed and then never unclaimed because a worker died at the wrong moment. This is Part 6 of my series How to Architect an Enterprise AI System (And Why the Engineer Still Matters). Part 5 (Feature Flags as Guardrails) was about preventing unsafe behavior from ever shipping. This part is the opposite kind of guardrail: the one you build when you want concurrency, retries, and recovery to be boringly deterministic. The key insight (and the bug it prevents) For a large class of workloads, I do not treat a queue as a separate infrastructure primitive. I treat it as a table with state, and I let PostgreSQL enforce the one thing distributed workers are worst at enforcing themselves: Only one worker can own a unit of work at a time That sounds obvio