1Stop

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

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