"Atomic": All of It, or None of It

DEV Community

The metaphor: stapling pages together

Imagine a contract with two pages: "take 50ドル from Alex" and "give 50ドル to Sam."

If the pages are loose, someone could grab page one and drop page two. Disaster.
So you staple them together. Now they move as one thing. Either both pages go
through, or neither does. You can't tear them apart.

NOT ATOMIC ATOMIC (stapled)
[ take 50ドル ] done [ take 50ドル ] \
[ give 50ドル ] CRASH } both, or neither
money lost [ give 50ドル ] /

"Atomic" comes from the old idea of an atom: something you cannot cut in half.

How you actually do it: a transaction

In databases, you staple steps together with a transaction.

-- Wrong way: two separate steps. A crash between them loses money.
UPDATE accounts SET balance = balance - 50 WHERE name = 'Alex';
-- ... crash here ...
UPDATE accounts SET balance = balance + 50 WHERE name = 'Sam';
-- Right way: staple them. All of it, or none of it.
BEGIN;
 UPDATE accounts SET balance = balance - 50 WHERE name = 'Alex';
 UPDATE accounts SET balance = balance + 50 WHERE name = 'Sam';
COMMIT; -- if anything fails before this, ROLLBACK undoes the whole thing

BEGIN starts the staple. COMMIT makes it real. If something breaks in
between, a ROLLBACK throws the whole half-done mess away, like it never started.

A real case

Any time two things must be true together, you want atomic:

Move money between accounts.
Book the last concert seat AND charge the card.
Create a user AND give them a starter project.

If only one half lands, you get "ghost" data: a charge with no seat, a user with
no project. Atomic operations keep those from ever existing.

Gotchas juniors hit

1. Doing related writes as separate, unprotected steps.
Two UPDATEs in a row are not safe just because they sit next to each other in
your code. Wrap them.

2. Confusing atomic with "fast."
Atomic is about all-or-nothing, not speed. A slow operation can still be atomic.

3. Thinking one row is always safe but many rows aren't.
A single statement is usually atomic on its own. The danger shows up when one
logical action needs multiple steps. That's when you reach for a transaction.

Recap

Atomic = all of it, or none of it. No half-done state.
Picture stapled pages: they move together or not at all.
In databases, you get this with a transaction (BEGIN ... COMMIT).
Use it whenever two or more changes must succeed together.

Your turn

Find a place in your app where you write to the database twice for one action.
Ask: "What if it crashes between the two writes?" If that scares you, wrap them
in a transaction. Now go explain "stapled pages" to a friend.