Transaction Mastery

Before ACID, before SQL syntax, before Spring — you need the idea in your bones. This chapter builds it from a story you already understand: standing at a bank counter.

The "A" in ACID, and the property Chapter 01's entire bank story was really about. This chapter goes from the plain-English idea to exactly how a database engine pulls it off.

The most misunderstood letter in ACID — mostly because the word "consistency" means something completely different in the CAP theorem. This chapter draws that line clearly.

The densest, most interview-tested ACID property. By the end of this chapter you'll be able to name every anomaly, every isolation level, and exactly which levels prevent which anomalies — from memory, not a lookup table.

The last ACID letter, and the one that answers a very specific, very practical question: when the database says "committed," what exactly is it promising survives a crash one millisecond later?

ACID was the theory. This chapter is hands-on-keyboard SQL — every statement you actually type to control a transaction's boundaries.

This is how isolation (Chapter 04) is actually implemented under the hood. It's also where "it worked in dev, it deadlocked in production under load" bugs are born and understood.

Everything in Parts 1–3 was database theory. This chapter is where it becomes one annotation — and the single most misunderstood rule in Spring: not every exception rolls back your transaction.

What happens when a @Transactional method calls another @Transactional method? Seven possible answers exist, and this is the chapter that makes all seven concrete instead of memorized.

The chapter that explains the single most confusing real-world @Transactional bug: "I called my own method, and the transaction just... didn't happen." This is why, exactly.

Closing out Part 4: when you'd reach for imperative transaction control instead of the annotation, and what happens to all of this once your stack is reactive.

You've never called.save() after modifying a loaded entity, and it still worked. This chapter is why — and it's one of the most-asked internals questions in mid-to-senior Java interviews.

Closing out Part 5: the full entity state machine, the two-level cache, and exactly where a transaction boundary sits relative to all of it.

"MongoDB doesn't support transactions" was true once, and is a genuinely dangerous half-truth to repeat in an interview today. This chapter is exactly what's true now, and exactly what still isn't.

Every chapter until now assumed one database. This chapter is the problem statement for the rest of Part 7 — the moment "just wrap it in @Transactional" stops being an answer.

The classical, textbook answer to Chapter 15's problem. Every interview expects you to know it — and to know exactly why it's rarely the answer chosen in practice at real scale.

The pattern actually running in production at most real microservices companies. This is the single most system-design-interview-relevant chapter in this entire book.

Closing Part 7 by solving Chapter 15 §3's specific dual-write problem — the pattern that makes every saga step in Chapter 17 actually reliable in practice, not just in theory.

Chapter 17 kept saying "idempotency is required because delivery is at-least-once." This chapter is the mechanism Kafka itself provides to tighten that guarantee — and exactly what "exactly-once" does and doesn't promise.

Every pattern from Parts 1–8, applied to the exact systems interviewers ask about most: UPI, wallets, inventory, and ride-sharing. This chapter is where the theory becomes design-round-ready.

Every pattern in this book, viewed from 3 AM on-call: how transaction problems actually announce themselves in production, and how to find and fix them fast.

Every chapter built or hardened one piece. Here is the whole book, assembled into one system — plus a final cheat sheet and mock-interview script to run yourself through before the real thing.