
ACID Transactions: The Database's Unbreakable Vow
Why banks use RDBMS over NoSQL. A deep dive into Atomicity, Consistency, Isolation, Durability, Transaction Isolation Levels, Deadlock prevention, and how to ace this topic in technical interviews.

Why banks use RDBMS over NoSQL. A deep dive into Atomicity, Consistency, Isolation, Durability, Transaction Isolation Levels, Deadlock prevention, and how to ace this topic in technical interviews.
Why does my server crash? OS's desperate struggle to manage limited memory. War against Fragmentation.

A deep dive into Robert C. Martin's Clean Architecture. Learn how to decouple your business logic from frameworks, databases, and UI using Entities, Use Cases, and the Dependency Rule. Includes Screaming Architecture and Testing strategies.

Two ways to escape a maze. Spread out wide (BFS) or dig deep (DFS)? Who finds the shortest path?

Fast by name. Partitioning around a Pivot. Why is it the standard library choice despite O(N²) worst case?

When I first learned backend development, I treated databases like simple spreadsheets. I thought INSERT meant save, and SELECT meant read. It seemed straightforward. But as I studied financial system case studies, I encountered a reality that changed my perspective forever.
Imagine a simple money transfer scenario: Alice sends $1,000 to Bob. Without transactions, the code looks like this:
When the system comes back up, Alice's balance is down by $1,000, but Bob received nothing. The money just evaporated into the digital void.
This scenario teaches us that Databases aren't just about 'Storage'; they are about 'Guarantee'. The reason why financial institutions stick to "slow, expensive, hard-to-scale" RDBMS over shiny new NoSQL databases is primarily because of Transactions and the ACID properties. It's a contract that says, "I will keep your data safe, no matter what."
To guarantee data integrity, a database transaction must adhere to four key properties. These are non-negotiable rules and the most fundamental database concepts.
Everything succeeds, or nothing happens. There is no middle ground. If you have 100 SQL statements and the 100th one fails, the database must undo the previous 99.
Data must always satisfy all defined rules (Constraints, Foreign Keys).
CHECK (balance >= 0) constraint), the database must reject the entire transaction. It prevents "illegal" data from ever entering the system.Concurrent transactions happen independently. Even if Alice and Bob are updating the database at the exact same millisecond, they should not see each other's intermediate states.
Once a transaction is committed, it remains committed even in the event of a system failure.
The most complex part of ACID is Isolation. It's always a trade-off. How much performance are you willing to sacrifice for data accuracy? This is where juniors get separated from seniors.
In a multi-server environment (Microservices), DB locks might not be enough. If you have 10 API servers, a standard DB lock within a transaction only works for that specific DB connection session (mostly).
We use Redis Redlock: SET key value NX PX 10000. Only one server gets the lock, ensuring atomicity across distributed systems (e.g., handling flash sales for limited inventory).
As you increase isolation levels, you inevitably face Deadlocks—two transactions waiting for each other forever. This is a classic "chicken and egg" problem in database management.
Imagine Transaction A holds a lock on Row 1 and needs Row 2. Meanwhile, Transaction B holds a lock on Row 2 and needs Row 1. Neither can proceed, and they will wait indefinitely until the database engine steps in and kills one of them (usually the one that did the least work).
WHERE clauses for updates.Read Committed instead of Serializable or Repeatable Read.Q. When should I use NoSQL vs RDBMS? A. Use NoSQL if your schema changes frequently (Schema-less), you need massive read/write scale, and can tolerate eventual consistency. Use RDBMS if data integrity (ACID) is paramount, like in financial or inventory systems.
Q. Why use @Transactional(readOnly = true)?
A. For performance. It effectively tells the JPA provider (Hibernate) "I won't optimize this track changes," so it skips dirty checking, saving memory. It also hints to route queries to a Read Replica database interaction.
Understanding ACID isn't just for passing interviews. It's about knowing the limits of your system.
As a developer, "It works on my machine" is not enough. You must understand how your database handles concurrency, what isolation level you are running on, and how to handle failures gracefully. That's the difference between a coder and an engineer.
I hope this note helps you understand ACID not as a textbook concept, but as a survival tool for your data. The scenarios described here are the exact reasons financial systems are built the way they are. I hope this saves you from learning those lessons the hard way.