Java

It’s 3 AM. A customer paid, the orders row is in your database, and the OrderCreated event never reached Kafka. The warehouse never shipped. The email never sent. Somewhere in your service there is code that looks like this: @Transactional public Order placeOrder(PlaceOrder cmd) { Order order = orderRepository.save(new Order(cmd)); // write #1 kafkaTemplate.send("orders", order.getId(), toJson(order)); // write #2 — outside the safety net return order; } Two writes. No shared atomicity. If the broker is down, if the pod gets killed, if the send times out after the commit — the database and the downstream world silently disagree, and you get to find out from an angry customer. This is the dual-write problem, and the fix is the transactional outbox pattern. ...

The client times out waiting for your POST /orders. It retries. Your server processes it twice. The customer gets charged twice, and your support queue gets a new entry titled in all caps. Stripe solved this a decade ago with one header: Idempotency-Key. The client generates a UUID, sends it with the request, and retries with the same key — Stripe guarantees one effect per key. It’s the industry reference implementation (docs, engineering blog), and there’s no reason your API can’t offer the same contract. Let’s build it. ...

“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. ...