Spring-Boot

It’s 3 AM again. A customer placed an order, payment went through, and inventory reservation failed — the warehouse is out of stock. The customer has been charged for something that will never ship. The order row exists and the customer was charged, but nothing will ship — and no single transaction can unwind it, because there is no @Transactional that spans your order service, your payment service, and your inventory service. Each one already committed its own local transaction. ...

Adding gRPC to Spring Boot traditionally meant choosing a third-party starter such as LogNet or yidongnan, managing gRPC versions, and dealing with server configuration yourself. Spring gRPC 1.0 made it official but kept the auto-configuration outside Boot. Spring Boot 4.1 finished the job: the auto-configuration moved into Boot itself, the starters are on start.spring.io, and the BOM manages the versions of the gRPC dependencies it provides. If you’re comfortable building REST endpoints with Spring, Spring Boot 4.1 makes the gRPC programming model feel surprisingly familiar. ...

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

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