Java

“Design a distributed cache.” You say hash(key) % N. The interviewer nods, then asks: “A node dies at 3 AM. What happens?” If your answer is “we rehash everything,” you’ve just told them your cache has a planned outage every time the cluster changes shape. This post builds the real answer — a working consistent hash ring in Java, with virtual nodes and tests — and the lineage and follow-ups that turn it into a senior-level answer. ...

It’s 3 A.M. PagerDuty is screaming, the error rate graph looks like a hockey stick, and your Java service is dying. You have SSH, a shell, and about ten minutes before someone important wakes up. This is the triage ladder I actually run, in order, with the exact one-liners. The order matters: every step rules out a class of problem before you spend time on the next one. If you did the hardening from the Linux Server Setup post, this is its companion — that one was pre-incident, this one is during. ...

You bumped spring-boot-starter-parent to 4.1, ran the build, and noticed something in the test output: junit-jupiter:6.x. Nobody asked for it, nothing in your test code changed, and everything still passes. So what did you just get — and what breaks the day it doesn’t? Short version: JUnit 6 is mostly a cleanup release wearing a major version number. For a typical Spring Boot app, the migration is deleting lines from your pom.xml, not adding them. The pain lives in three specific removed APIs and two build plugins. Let’s go through all of it with code. ...

Rate limiting shows up in two places: your on-call rotation and your system design interview. Both reward the same thing — knowing which algorithm to pick, why, and what breaks at scale. This guide builds three working limiters in Spring Boot, each with tests: Fixed window — the simplest thing that works, hand-rolled. Token bucket — smooth, burst-friendly, via Bucket4j. Distributed sliding window — precise and shared across instances, on Redis with Lua. Then we close with the part interviews actually grade: how to talk through the tradeoffs. ...

Virtual threads can be one of the easiest throughput wins in a blocking Spring Boot application. The switch is one line: spring: threads: virtual: enabled: true But that line changes the concurrency model of the application. It does not make database queries faster, reduce API latency, or create more database connections. It makes waiting cheaper by allowing many request tasks to share a smaller number of carrier threads. ...