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.

Functional core, imperative shell usually gets pitched as a full architecture: pure domain functions in one layer, all I/O pushed to the edges, everything wired together through explicit ports.

Memory is not a receipt. A landlord and a tenant agree a flat is fine at handover; six months later they remember it differently. A fleet manager hands over a van with a full tank and no dents; a week later, someone disputes which of those was true.

Someone close to me is a photographer who needed a portfolio site but doesn’t want to touch a terminal, a code editor, or a “deploy” button.