Race Conditions: How to Spot and Prevent Data Conflicts

Several parallel processes are supposed to speed up data processing. But what happens if each of them sees the same records and decides that it should be the one to process them?

In this talk, we will explore what a race condition is, why individually correct operations can lead to an incorrect overall result, and how concurrent access to data can be managed.

Using a high-load platform as an example, I will show how two parallel processes could start the auto-renewal of the same subscription at the same time and create two separate payments. I will explain why having an idempotency key alone does not solve the problem.

We will discuss transaction boundaries, atomicity, and idempotency. We will look at why two technically correct requests can still be duplicates of the same business operation, and how to design system-level protection against this.