I’ve dealt with race conditions quite a bit in distributed systems. The fix really depends on where the race is happening.

For duplicate writes, I usually start with idempotency and enforce uniqueness at the database level. For competing updates, optimistic locking or atomic database operations are often enough.

Across multiple services, I’ll typically use patterns like idempotent consumers, transactional outbox, or sagas rather than trying to lock everything across the system.

The biggest thing is not to over-engineer it. First identify the actual race... duplicate writes, lost updates, out-of-order events, etc. then put the consistency guarantee as close to the data as possible.

If you want to walk through your specific architecture and race condition, feel free to book a call.