Question: What happens when the same project is saved from two places at once?
Two saves, one project
I had two tabs open on the same project. I saved from both. I didn't think that would be a problem. A save is a save.
It shouldn't have been possible to collide
I'd only ever pictured one tab, one save, one flow. It wasn't until I typed the sentence "what if two registration requests land at the same time" that it actually hit me. Nothing guaranteed the server would take them in order.
Wrong assumption: add a state, and the collision goes away
My first instinct was a two-step reserve-then-commit flow. A request comes in, gets marked pending, and only becomes final once nothing else has claimed the same key. It's a pattern I'd seen everywhere, so it felt like the obvious right answer.
The why chain
Why did I think a reservation step was necessary? If two requests land at once and each mints its own project_id, I'd end up with duplicate rows for the same project. A reservation step, I thought, would catch that collision before it happened.
Why didn't the reservation step actually remove the collision? Because commit was still a separate step after reservation, and commit could fail too. If both requests succeeded at reserving, the exact same collision just showed up again — one step later. Adding a state didn't remove the race. It only moved it.
Why did I assume the application had to solve this at all? The rule — one registration key, one project — already existed. I assumed enforcing it was my job, something I had to build logic for. It wasn't. It was a rule the database already knew how to enforce on its own.
Decision: stop rebuilding what the database already guarantees
I dropped the reserve-then-commit idea and let a uniqueness constraint on the registration key do the work directly. Two requests can arrive together, and the database enforces the uniqueness constraint — no extra state, no in-between status to reconcile later.
Every solution I'd come up with had the same shape. It added more application logic to enforce a rule that already belonged to the database.
I wasn't solving the race. I was recreating the database.
Every version of my "solution" was really just rebuilding a guarantee that already belonged to the database — reservation, commit, lock, whatever shape it took. The race wasn't waiting for me to design a fix. It was waiting for me to stop assuming the fix had to live in my code.
Most of the work isn't building the solution. It's discovering what the problem actually is.
Wrong assumption: A race condition needs a reserve-then-commit state machine to prevent it
Discovery: Adding a state doesn't remove a race — it only moves it. The guarantee already belonged to the database.
Next step: Both requests now land on the same project_id, win or lose. But once two tabs agree on which project they're both editing, what happens when they disagree on what's in it?
The race wasn't the problem. Rebuilding the database was.