Every business application uses a relational database as a backend persistence for data. When we talk about relational databases, we cannot exclude database servers such as Microsoft SQL Server, Oracle, IBM Derby, and so on, used to create the databases, tables, stored procedures, and other useful objects. Relational databases also exhibit properties known as the acronym ACID (Atomicity, Consistency, Isolation, and Durability):

• Atomicity: Multiple operations can be done on a database as a unified transaction which can either succeed or fail. On failure, all the operations will be rolled back to the previous state.
• Consistent: Avoid inconsistencies in results, like keeping the atomicity and avoiding partial changes to the database
• Isolation: Concurrent transactions cannot read each other's data. This means that if two transactions are being executed, and if some transaction has to read the data, then it has to wait until the other transaction commits its changes.
• Durability: Once the transaction is committed, the changes are saved in the database and can be retrieved later.

An ACID transaction is the true essence of any enterprise application that involves lots of database operations. However, the consistency and isolation attributes highly affect scalability, as we know that consistency does not allow partial updates and Isolation avoids any other concurrent transaction to wait until the first one is completed. Hence, if the number of concurrent transactions are higher because of scaling out our databases, the number of transactions increases as well, and affects the overall performance of the application.

We will discuss the solution to this problem in the following sections.