|
Latest articles
If you’re not a subscriber, here’s what you missed this month.
 |
Database Schema Design Simplified: Normalization vs Denormalization
SQL vs NoSQL: Choosing the Right Database for An Application
To receive all the full articles and support ByteByteGo, consider subscribing:
Modern applications don’t operate in a vacuum. Every time a ride is booked, an item is purchased, or a balance is updated, the backend juggles multiple operations (reads, writes, validations) often across different tables or services. These operations must either succeed together or fail as a unit.
That’s where transactions step in.
A database transaction wraps a series of actions into an all-or-nothing unit. Either the entire thing commits and becomes visible to the world, or none of it does. In other words, the goal is to have no half-finished orders, no inconsistent account balances, and no phantom bookings.
However, maintaining correctness gets harder when concurrency enters the picture.
This is because transactions don’t run in isolation. Real systems deal with dozens, hundreds, or thousands of simultaneous users. And every one of them expects their operation to be successful. Behind the scenes, the database has to balance isolation, performance, and consistency without grinding the system to a halt.
This balancing act isn’t trivial. Here are a few cases:
One transaction might read data that another is about to update.
Two users might try to reserve the same inventory slot.
A background job might lock a record moments before a customer clicks "Confirm."
Such scenarios can result in conflicts, race conditions, and deadlocks that stall the system entirely.
In this article, we break down the key building blocks that make transactional systems reliable in the face of concurrency. We will start with the fundamentals: what a transaction is, and why the ACID properties matter. We will then dig deeper into the mechanics of concurrency control (pessimistic and optimistic) and understand the trade-offs related to them.
 |
