Spring-Boot

You migrated to Spring Boot 4. The app boots. Then a RestClient call starts blowing up on payloads that carry explicit nulls for primitive fields — even though your ObjectMapper config disables FAIL_ON_NULL_FOR_PRIMITIVES (your clients send those nulls; Jackson 2 let them through). You stare at the config bean. It’s right there. It’s also completely ignored — and Jackson 3 flips that feature to fail-by-default, so the new default silently takes over. ...

It’s 3 AM and the payment provider is timing out. The fix is one property: raise payments.timeout from 5s to 15s until their incident clears. But that property lives in application.yml, baked into the jar, deployed to twelve instances. So you rebuild, push, and roll twelve restarts — for a value that isn’t code. Externalized configuration is the pattern that ends this ritual: configuration lives outside the deployable artifact, in one versioned place, and services pick it up at startup — or at runtime, without restarting. Spring Cloud Config is the canonical Spring implementation, and it pairs with the config-data import that replaced the old bootstrap.yml setup back in Boot 2.4. ...

It’s 3 AM. A payment flow is failing for one customer out of thousands, and you’re grepping 40,000 lines of timestamp-soup for a single orderId — a value buried inside a formatted message, different on every line because someone wrote "order " + id + " failed" in one place and "failed order=" + id in another. This post kills that workflow. Structured logging turns every log line into a JSON document with named, typed fields your ELK stack can filter, aggregate, and alert on. Spring Boot has supported it natively since 3.4, and on Boot 4 it’s a one-property switch — no logstash-logback-encoder, no XML wrestling, no code changes. ...

Every Spring codebase has one: the PaymentsClient class. Sixty lines of restTemplate.exchange() with string-concatenated URLs, an HttpEntity built by hand for every POST, a try/catch that maps HttpStatusCodeException to something the caller understands, and a custom ResponseErrorHandler someone wrote in 2021 that nobody dares to touch. It works. But the platform is moving on, and there are now two modernization paths worth knowing. The first is the modern imperative successor: Spring Framework 7 deprecates RestTemplate in favor of RestClient — new imperative clients should generally prefer RestClient, while existing working RestTemplate code doesn’t require a flag-day rewrite. The second is the declarative HTTP client: an interface, some annotations, and no handwritten implementation class. It is not a replacement for RestClient — it is an interface/proxy abstraction that sits on top of an underlying HTTP client: ...

Your checkout service calls the payment gateway. One night the gateway has a bad deploy and starts timing out. Every synchronous checkout request thread now remains occupied for the full 10-second client timeout. Threads pile up, the pool exhausts, health checks fail, and the load balancer starts draining your perfectly healthy checkout pods. Nothing about checkout is broken — it just never stopped calling a dependency that was already dead. ...