A race condition happens when two operations touch the same thing at nearly the same time and the outcome depends on which one gets there first. A classic case is two people booking the last appointment slot: both check that it is free, both see yes, and both book it.
These bugs are hard to reproduce because they depend on timing, so they often show up only under real load, and pass every test you run by hand. They are common in automation, where two webhook deliveries or overlapping workflow runs can work on the same record.
Ways to prevent them: make the check and the change a single atomic step, use database constraints such as unique keys so the second write fails safely, use locks or queues to handle one at a time, and design operations to be idempotency-safe. Then handle the failure path with error handling, for example by telling the second person the slot is taken.
Related: Workflow Automation, API, Retry Logic.