You send money to a friend. The app takes $50 out of your account. Then, right
in the middle, the server crashes. Your $50 is gone, but your friend never got
it. Money just vanished into the void.
That nightmare is exactly what the word atomic is here to prevent.
The idea in one line
An atomic action either fully happens or fully doesn't. There is no
half-finished, in-between mess.
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.
Top comments (0)