It sounds like this“My app is fine with a file because users only save one at a time.”

Thinking users politely take turns

2 min readBy the Cognosc teamPart of Why use a database instead of just saving files?

Why it feels right

When you test an app alone, it is one person at a time, and the file behaves perfectly. It is natural to think the real world is the same: people click at different moments, each click is fast, so surely they don't collide. The bug is rare, which is exactly why it feels as if it can't happen.

Why it’s wrong

At any moment two requests can be in the middle of the same read, change and write. Each reads the same old value, and whoever writes last wipes out the other's change. A database gives you locks or transactions to stop that.

A worked example

Saving a number looks like one step but is three: read the file, change the value in memory, write it back. Take a balance of 100 stored in a file. Process A reads 100 and starts adding 10. A moment later process B reads the same file, still 100, and starts adding 20. A writes 110. Then B writes 120. The file now holds 120, where the right answer is 130. A's deposit has vanished and nobody was told.

The window is small, perhaps a few milliseconds, but a busy site has thousands of requests a second, so some of them will land inside it. The failure shows up as odd missing data, weeks later, and can't be reproduced on demand.

A database guards against this with locks, or by running each change as a transaction that others have to queue behind. You can do the same with files, using lock files and careful ordering, but you are then writing a small database yourself, and getting it right is harder than it looks.

How to catch yourself

  • You say 'it's fine, two people won't save at the same moment'.
  • You read, change and write a file without any lock.
  • You can't reproduce a missing update, so you decide it was a one-off.

What to hold instead

The better idea

Two requests can read the same old value, change it and write it back, and the later write erases the earlier one. A database puts changes in order with locks or transactions so no update is lost.

Where you’ll meet it

  • Adding up counters, balances or stock levels from many users.
  • Chasing a bug where data goes missing now and then.
  • Deciding whether a shared file is safe enough.

Questions people ask

What is a lost update?
When two processes read the same value, each changes it, and each writes it back, so the second write overwrites the first. One of the two changes is silently lost.
How do databases prevent lost updates?
They use locks or transactions to make competing changes happen one after another, or they detect the clash and make one of them retry, so every change is applied to the latest value.

Where it’s taken apart

Caught by it?

Cognosc spots mistakes like this one.

It shows you what really happens, names the exact idea that led you off, and keeps checking you still understand the right one.