Leverage databases to avoid concurrency problems

Tracking and fixing concurrency bugs can be pretty hard because of the nature and occurrence of these issues.

First off, concurrency issues only come into play when one transaction reads data simultaneously modified by another transaction or when two transactions modify the same data. This is a rare occurrence as it only happens when the system is loaded beyond a certain limit, which depends on the number of CPUs, programming language, and data architecture.

Next, concurrency issues are difficult to test or reproduce; they happen only when you are unlucky with timing. One could write tests to reproduce the bug by tightly controlling the execution and timing, using locks and semaphores, for example. But this takes effort and time, as well as an excellent working knowledge of concurrency programming.

Concurrency is also very difficult to reason about, especially in a large application with many moving pieces. Without good architecture or design pattern in place, any part of the system may change any piece of data, making the task of discovering possible concurrency issues tricky.

For this reason, when there are chances that an application may experience concurrency issues (in other words, needs transactions), it may be best to use a database that comes with safety guarantees built-in. Databases have long tried to hide concurrency issues from application developers by providing transaction isolation.