Compare-and-swap means: change this row, but only if it is still what I last saw. In SQL that’s an UPDATE with a guard in the WHERE clause, and you check how many rows it touched.

FOR UPDATE locks the rows a query returns. Add SKIP LOCKED and a row that another transaction has already locked is skipped instead of waited for.

Eight workers poll the same jobs table. Each job must be processed by exactly one of them. Two PostgreSQL tools solve this, FOR UPDATE SKIP LOCKED and compare-and-swap (CAS), and on the same workload one claimed every job it tried for while the other lost most of its attempts.

Say a limiter allows 100 requests per minute. At 11:59:59 a user sends 100. At 12:00:01 they send 100 more. That’s 200 requests in 2 seconds, and one common implementation lets all of them through.

Two production Node apps — Handovha and Mail Koenig — run on one DigitalOcean droplet at the smallest tier DigitalOcean sells. No Kubernetes, no Terraform, no PaaS.

Sending an email campaign to a few thousand people looks simple until the third recipient’s inbox provider rate-limits you mid-send, the fourth bounces permanently, and the process doing the sending gets killed by a deploy halfway through.