Your Code Will Break Someday — But Your Data Should Never🙅‍♂️

If your data breaks, it breaks your user’s trust — and that is very hard to rollback.

This one line captures the harsh reality of software development. No matter how good your code is, bugs will happen. Features will misbehave. APIs will go down. Users will forgive a temporary glitch, but if their money vanishes, their order history is wrong, or their data is corrupted, they will lose trust forever.💔

Data is sacred because of the ACID principles🔐.

In this article, I won’t be covering boring academic theory. You’ll learn practical ACID, with real-world analogies and code examples, so that you can apply this in your project today.

Image created by author

What is ACID? And Why Should You Care?

ACID is a set of four key properties who guarantees that database transactions are processed reliably.

⚛️Atomicity

🎠Consistency 🧪Isolation 🛠️Durability

Now, why should YOU care?

Because without ACID:

• Your UPI/Credit-Card transfer may deduct money, but not credit it.
• Your e-commerce site may sell 100 items, but show only 98 sold.
• Your booking app may double-book a movie seat.

ACID protects your app — and more importantly, your users’ trust🤝.

Let’s break it down.

1. A = Atomicity⚛️

“Do all, or do nothing.”

Imagine you’re withdrawing ₹2000 from an ATM. If the machine gives you cash but the bank fails to deduct it from your account, you get free money, right? Or worse — if it deducts money but gives no cash!😂

Atomicity ensures that such partial operations never happen.

In technical terms:

• A transaction is atomic if either all operations inside it succeed, or none of them do.

In Java Spring Boot:

@Transactional
public void transferFunds(String fromAccount, String toAccount, BigDecimal amount) {
    accountService.debit(fromAccount, amount);
    accountService.credit(toAccount, amount);
}

If any part (debit or credit) fails, the entire transaction is rolled back. No money is lost in limbo.

Common mistake: Not using @Transactional properly → partial writes → data corruption.

My tip: Always test failure cases → unplug DB, throw exceptions → ensure rollback works.

2. C = Consistency🎠

“Your data should always be valid.”

Let’s say you run an e-commerce site. Your DB has two tables:

• Orders → Each order must reference a valid customer.
• Inventory → Quantity should never be negative.

Consistency means that any transaction must bring the database from one valid state to another.

Example: A product has stock = 2. Two people place orders at the same time. Your app must ensure that stock never becomes -1.

Tools for consistency:

• DB constraints → Foreign key, Unique, NOT NULL, CHECK.
• Application logic → Additional validation.

Spring Boot Example:

//Entity Order class
@Entity
public class Order {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne
    @JoinColumn(name = "customer_id", nullable = false)
    private Customer customer;

    private BigDecimal amount;
}

Now, if you do this:

Customer fakeCustomer = new Customer();
// Assume this customer does not exist in DB
fakeCustomer.setId(99999L);

Order order = new Order();
// Setting an invalid customer reference
order.setCustomer(fakeCustomer);
order.setAmount(new BigDecimal("500"));

// This will throw an exception!(Consistentcy😉)
orderRepository.save(order);

What will happen in the background?

• Hibernate will generate an INSERT statement with customer_id = 99999.
• The DB will check the FOREIGN KEY constraint.
• Since customer_id = 99999 does not exist → DB will throw an error(e.g. ConstraintViolationException).
• Hibernate will map that DB error to an exception → and your transaction will rollback.

My tip: Don’t rely on app code alone → always enforce key constraints at the DB level too.

3. I = Isolation🧪

“Transactions should not interfere with each other.”

This is where many developers (including me, early on!) get it wrong.

Let’s say two people are trying to book the last seat in a movie.

If your app doesn’t handle isolation properly:

• Both transactions might see “Seat Available”.
• Both confirm the booking.
• Now 1 seat is double-booked → customer anger → refunds → reputation loss.

Isolation Levels (Simple View):

Isolation Levels

In Springboot:

@Transactional(isolation = Isolation.SERIALIZABLE)
public void bookSeat(Long seatId) {
    Seat seat = seatRepository.findById(seatId);
    if (seat.isAvailable()) {
        seat.markAsBooked();
        seatRepository.save(seat);
    }
}

At SERIALIZABLE, two concurrent transactions will be prevented → one will wait or fail.

Common mistake: Using default isolation everywhere → sometimes too weak.

My tips:

• Choose isolation based on use case.
• Not every query needs SERIALIZABLE → tradeoff between correctness & performance.

NOTE: For a better understanding of Different Isolation Levels, Propagation Types, and Rollbacks, I would highly recommend that you do check out my article: https://medium.com/javarevisited/you-think-you-know-transactional-think-again-817d1412b562

4. D = Durability🛠️

“Once committed, data survives forever (even when power loss).”

Imagine you did a UPI payment of ₹5000. Just after pressing “Pay”, your phone battery dies. You reopen the app → was the payment done?

Thanks to Durability, the DB ensures that if a transaction was committed, it is stored permanently, even if:

• Server crashes.
• Power failure happens.
• Application restarts.

How?

• DBs use write-ahead logs (WAL), redo logs, etc.
• The commit is written to durable storage before acknowledging success.

In Springboot:

• No special code needed — your DB handles this behind the scenes.🪟

But you must ensure:

• Transactions commit only when all operations are truly done.
• You are not using volatile / in-memory DBs for critical data.

My tip: Test your durability → simulate crashes → ensure no data loss after reboot.

Common ACID Violations in Real Projects

I’ve seen fellow devs making these mistakes in real projects:

☣️Using @Transactional, but calling other methods internally → no real transaction. ☣️Not using DB constraints → app logic fails → DB allows invalid state. ☣️Not testing concurrent transactions → isolation bugs → data mismatch. ☣️Using non-durable storage for critical paths → data lost on crash.

Real Example: A fintech app in India once had a bug where failed UPI refunds were marked as success because the transaction table write failed, but the app didn’t rollback properly. Result → Customer balance mismatch → huge manual reconciliation effort.

Best Practices To Achieve ACID In Your Projects

· Use @Transactional religiously for multi-step writes.

· Understand and set the proper Isolation Level.

· Enforce strong DB constraints → never trust app logic alone.

· Simulate and test failures → network loss, power crash, DB crash.

· Monitor for anomalies (duplicate rows, missing data, negative stock).

· Educate your team → ACID is not optional.

📒 Quick Checklist:

• [ ]Every critical write is wrapped in @Transactional.
• [ ]Foreign keys, Unique, CHECK constraints in place.
• [ ]Isolation levels are documented and chosen wisely.
• [ ]Durability tested by simulating restarts.
• [ ]Monitoring and alerting on data anomalies.

👋Final Thoughts

“Code can fail and be fixed. Broken data stays broken in your user’s heart.💔”

As developers, we love writing features fast. But remember — your first responsibility is protecting your users’ data.

⇛Bugs can be fixed. ⇛Features can be improved. ⇛But corrupted data? That can haunt your product for years.

So next time you write code, ask yourself:

⇛Will my transaction be atomic? ⇛Is my data always consistent? ⇛Are my transactions isolated correctly? ⇛Is my data durable, no matter what happens?

If the answer is “yes”, congratulations!🎉

Your users may never know ACID exists — but they will trust your app because of it. 🙌😊

If you found this article useful, please do me a small favour: 👏Hit that Clap button (you can press it up to 50 times — try it!) 💬Leave a comment with your thoughts or any ACID-related war story you’ve faced 📤Share this article with your fellow devs and on LinkedIn/X— trust me, many of them need this today!

I genuinely hope this article helps you write safer, more reliable software. Your users may never know ACID exists — but they will trust your app because of it. 🙌