Java

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

“Find the k largest elements in this array.” Most candidates reach for Arrays.sort() and stop. It works. It’s O(n log n). A stronger answer reaches for the heap: sorting processes all n elements in O(n log n) time, while a bounded heap takes O(n log k) and maintains only k candidates — preferable when k is small relative to n, or when the input arrives as a stream. For 1 ≤ k ≤ n, the heap uses O(k) auxiliary space, and the returned result uses O(k) output space. This post builds four common heap patterns that cover a wide range of top-k questions asked in Java interviews, with working code, the complexity math, and the PriorityQueue traps that quietly sink candidates. ...

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