1Stop

A ship stays afloat when one compartment floods because bulkheads — the watertight walls between sections — keep the water in one place. Your service has the same problem in reverse: one slow dependency floods the shared thread pool, and everything else drowns with it. A payment provider that takes 2 seconds instead of 200 milliseconds doesn’t just make payments slow. It occupies every request thread until the pool is full, and then your health endpoint, your login page, and your fast internal calls all queue behind it. The service isn’t broken. It’s busy — on someone else’s problem. ...

@Transactional is the most trusted annotation in Spring Boot — and the most quietly misunderstood. It looks like one annotation doing one job: wrap this method in a transaction. In practice it is a proxy, a set of defaults inherited from EJB, and a handful of hints to Hibernate, and each of those has a sharp edge. None of the five traps below throws an error at the point where you make the mistake. They all fail silently, in production, weeks later. ...

Apache Kafka 4.4.0 landed on October 22, 2026 — 25 KIPs and 963 commits since 4.3.0. Three things in it are worth your attention: share groups finally get dead-letter queues, Kafka Streams gets transactional state stores, and one storage change can surprise you during an upgrade. There is also a safety note that comes before all of it. First: if you run 4.3.x, patch to 4.3.2 first Kafka 4.3.2 shipped the very next day, October 23, and it is not a routine bugfix release. It fixes around 60 issues, including two potential data-loss bugs: ...

Think about the last PDF you “just quickly” edited online. A contract, a bank statement, a scanned ID, a tax form. You dragged it onto a website, the site did its thing, and you downloaded the result. That file — with your name, signature, and account numbers in it — passed through a server you don’t own, under a privacy policy you didn’t read, and you have no way to know whether it was deleted afterwards. ...

In the ThreadLocal leak post, ScopedValue was the third fix — two paragraphs and a filter snippet. This is the full treatment, because JDK 25 changed its status: after an incubator round in JDK 20 and previews in JDK 21–24, JEP 506 made java.lang.ScopedValue final in JDK 25. No preview flag. No incubator module. It is now part of the platform. First, the honest framing. “Replacement” comes with an asterisk: JEP 506 explicitly does not deprecate ThreadLocal, and migration is not a goal for every use. ScopedValue replaces the dominant request-context pattern: bind an immutable value at an entry point, let callees read it, and guarantee it disappears when that operation ends. It does not replace per-thread mutable caches, accumulators that callees update for a caller, or values that must outlive the method that created them. That distinction is the whole article. Get it right and ScopedValue removes a bug class. Treat it as a nicer global variable and you will recreate the ThreadLocal mess with newer syntax. ...