The worst Kubernetes outage I keep seeing is not a node dying. It is a slow database, a liveness probe that talks to that database, and a cluster that then kills every pod that was still doing useful work.

Liveness does not mean “the app is healthy.” It means “this process is so stuck that Kubernetes should shoot it.” If you point that gun at a dependency, you will shoot the fleet.

In review I still see @Transactional used as a blessing: put it on a method, and the database will behave. It will not. Spring starts a transaction when a proxy intercepts an incoming call. If the call never hits the proxy, you have no transaction, no rollback, and a very confusing production bug.

What I believed → what I do now

I used to sprinkle @Transactional on every service method “to be safe.” I now put it on the one method that is the use-case boundary, I write a test that proves rollback, and I treat same-class private calls as a smell.

A map of how I actually run backend software: Java on the JVM, Spring as the application layer, Kubernetes as the place it lives. Start here, then open the note that matches the problem in front of you.

This is not a tutorial index. It is the order I would walk a teammate through after an incident.

If you are new here

1. Spring @Transactional does not mean what you think — where transactions actually start, and why a method calling another method on this silently does nothing.
2. Liveness is not health — the Kubernetes outage that looks like a crash loop but started as a slow dependency.
3. Reliability lessons from SQLite — why a tool that solves more problems than it creates stays in production.

The Java course is the longer path if you want to write this stack with me, not only read about it.