DEV Community

Mohamed Idris
Mohamed Idris

Posted on

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

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 ]  /
Enter fullscreen mode Exit fullscreen mode

"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
Enter fullscreen mode Exit fullscreen mode

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)