Salman Saleem’s Post

You have a .NET service. Your team also has a Python ML service and a Java legacy beast that nobody wants to touch. They all need to talk to each other. So what do you do? You write REST APIs. Then you write OpenAPI specs. Then someone generates clients. Then the specs drift. Then you have a production incident at 2am because a field was renamed in the Python service and nobody updated the contract. The core problem isn't the technology choices – polyglot systems are genuinely valuable. The problem is the integration layer that has to exist between them. With REST or gRPC, the contract is a separate artifact from the code. Someone has to keep them in sync. That "someone" is a human. Humans make mistakes, get busy, leave the company. What if the contract was the code? What if calling a Python function from .NET looked the same as calling a local method – strongly typed, no JSON, no proto files? That's the direction Graftcode team has been exploring with graftcode.com. The package manager becomes your API client. Pull the package, call the method, done. Curious: how do you handle cross-language service contracts in your systems today? Still on OpenAPI? Protobuf? Something else? #microservices #polyglot #distributedsystems #softwarearchitecture #devex

A quick question that made me curious: What actually happens behind the scenes when we use @Transactional in Spring Boot? Most of us just add the annotation and trust it to handle everything. But under the hood, something interesting is happening. Spring doesn’t directly modify your method. Instead, it creates a proxy around the bean. So when a transactional method is called, the flow looks like: Client → Proxy → Transaction Manager → Your Method → Commit/Rollback Here’s what the proxy does: • Starts a transaction before method execution • Executes your business logic • Commits if everything is fine • Rolls back if an exception occurs But here’s another catch 👇 Not all exceptions trigger rollback. By default, Spring only rolls back for: • Runtime exceptions (RuntimeException) • Errors (Error) But checked exceptions (like IOException, SQLException) 👉 do NOT trigger rollback by default So sometimes: • Your code throws an exception • But the transaction still commits 😳 If you want rollback for all exceptions, you need: @Transactional(rollbackFor = Exception.class) And one more important catch: The proxy only works when the method is called from outside the bean. If one method inside the same bean calls another method annotated with @Transactional, the call bypasses the proxy. So the transaction may not even start. That’s why sometimes: • Transactions don’t work as expected • Rollbacks don’t happen • Bugs are hard to trace Spring isn’t “magic” — it’s just smart use of proxies and AOP. Now the interesting question: If method A and method B are in the same bean, and B is annotated with @Transactional, and A calls B internally… 👉 How would you make sure the transaction actually works? #SpringBoot #BackendEngineering #Java #SystemDesign #Transactional #AOP

#InfoQ dives deep into #SpringFramework 7 & #SpringBoot 4 with the team behind the code. 🛠️ Key Focus: the shift toward core resilience by integrating features such as retry and concurrency throttling directly into the framework, alongside the performance benefits of modularizing auto-configurations. Panelists • Phil Webb • Sam Brannen • Rossen Stoyanchev • Mark Pollack • Martin Lippert • Michael Minella • Karsten Silz - InfoQ Editor 🔗 Read now: https://bit.ly/48Qlj07 #Java #AIcoding #Microservices #SoftwareDevelopment

𝗪𝗲 𝗿𝗲𝗽𝗹𝗮𝗰𝗲𝗱 𝗚𝘂𝗮𝘃𝗮 𝗜𝗺𝗺𝘂𝘁𝗮𝗯𝗹𝗲𝗠𝗮𝗽 𝘄𝗶𝘁𝗵 𝗝𝗮𝘃𝗮 𝗠𝗮𝗽.𝗼𝗳. 𝗔𝗻𝗱 𝘁𝗵𝗲 𝘀𝘆𝘀𝘁𝗲𝗺 𝗯𝗿𝗼𝗸𝗲. 💥 The code still compiled ✅ Nothing looked suspicious 👀 It was a small refactor 🔧 But after the change, behavior was different. Tests started failing ❌ Output changed 📦 Part of the system behaved differently ⚠️ At first glance, this looked strange. We replaced one immutable map with another immutable map. So why did anything break? Because the system had a hidden dependency 🧠 It turned out part of our logic was relying on iteration order. Not explicitly. Not by design. Just implicitly, through how the map was being used. And that was the real problem. Nobody on the team expected that a map would become part of the behavior in that way 🤯 But it already had. So the issue was not just "Guava vs JDK". The issue was that we changed a piece of code without fully understanding what the surrounding system had started to depend on. The quick fix was simple: use LinkedHashMap and restore deterministic ordering ⚡ But the more interesting lesson was not about LinkedHashMap. The real lesson was this: When you replace something that looks equivalent, you may still be changing behavior. Same shape of API does not mean same semantics ❗ Same return type does not mean same guarantees ⚠️ And "it worked before" does not mean the dependency was valid. It may simply have been hidden. That is why before replacing a method, collection, or utility, it is worth understanding 2 things: 1️⃣ The behavior of the thing you are introducing 2️⃣ The behavior your system already depends on #java #springboot #backend #softwareengineering #refactoring #engineering #distributedsystems

Ever had a moment in your project where one API call waits… then another waits… and suddenly your entire system feels stuck? I faced this while building a real-time service. Multiple dependent calls were slowing everything down. That’s when I discovered CompletableFuture in Java. Instead of waiting → I started composing tasks. Fetch user data Fetch transaction history Fetch recommendations All running in parallel, not sequentially. And the magic? supplyAsync() – run tasks asynchronously thenApply() – transform results thenCombine() – merge multiple results exceptionally() – handle failures gracefully A simple shift from: Blocking code to Non-blocking, asynchronous pipelines Result? Faster response times. Better resource utilization. Happier users. In today’s world of microservices and real-time systems, mastering CompletableFuture isn’t optional — it’s a superpower. #Java #Concurrency #CompletableFuture #AsyncProgramming #BackendDevelopment

🎯 Day 8 🚶♀️➡️ 🚶♀️➡️🚶♀️➡️🚶♀️➡️🚶♀️➡️🚶♀️➡️🚶♀️➡️🚶♀️➡️ 🎯 Problem Name: Remove Nodes from Linked List 🚀 Problem Statement: Given the head of a singly linked list, remove all nodes where the value of the current node is less than the value of the next node. Return the modified linked list. 💡 Solution Approach: 1️⃣ Recursive Traversal: Start from the head and recursively process the next node. 2️⃣ Comparison: Check if the current node's value is less than the next node's value. If true, skip the current node by returning head.next. 3️⃣ Base Case: If the head is null, return null. 📊 Time Complexity: O(n) O(n) (Traverse all nodes once). 📊 Space Complexity: O(n) O(n) (Recursive calls stack). #CodingChallenge #LinkedList #ProblemSolving #DataStructures #Java #LeetCode

Day 22. I stopped using @JsonIgnore. Not because it doesn’t work. Because it hides problems instead of fixing them. I used to do this: @Entity public class User { @OneToMany(mappedBy = "user") @JsonIgnore private List<Order> orders; } Problem solved, right? No recursion. No crash. But here’s what actually happens: → You silently hide data from your API → Different endpoints return different shapes → Debugging becomes confusing → Your API contract becomes unpredictable That’s not a fix. That’s a workaround. Worse — @JsonIgnore is annotation-driven design. Your business logic is leaking into your data model. So I changed my approach. (see implementation below 👇) Instead of hiding fields, I control what gets exposed. DTOs. Now: → Every response is intentional → No hidden fields → No surprises for the client The hard truth: → @JsonIgnore is easy → DTOs take effort → That’s why most people choose the shortcut But shortcuts in API design become problems in production. I don’t use @JsonIgnore anymore. Do you? 👇 Drop it below #SpringBoot #Java #Hibernate #BackendDevelopment #JavaDeveloper

⏰ Temporary Field: When instance variables only show up for certain operations, cluttering your class interface with null-initialized fields. Here's how Extract Class refactoring transforms your code: ✅ Move temporary fields into dedicated classes ✅ Eliminate null-initialized field clutter ✅ Create clearer class interfaces ✅ Make object state predictable at every stage 🎯 Key takeaway: Extract Class refactoring organizes temporary state into focused objects that only exist when they're needed. What's your experience with refactoring Temporary Fields? Share your favorite techniques in the comments. #CleanCode #Refactoring #Java #TemporaryField #DeveloperTips https://lnkd.in/gJQeWPJ9

I once thought scheduled jobs were trivial: a Vercel cron job would call a Next.js API route to run Python logic. This broke down with timezone-aware scheduling, retry needs, and protecting the endpoint from public access. The cron would fire, but the function could fail silently, or the schedule drifted. I learned that mixing frontend hosting with backend scheduling creates a fragile single point of failure. Now, I separate concerns entirely. The UI remains in Next.js on Vercel. The job logic is a dedicated Python function deployed as a serverless container on Railway, behind an authenticated API route. I use cron-job.org as the external trigger. It calls the secured endpoint with a shared secret header and logs every execution. This decouples the scheduling mechanism from the application platform. I can monitor cron-job.org for missed pings and check the function's logs in Railway, providing two independent observability points. The key was reproducibility: the authentication secret and cron configuration are environment variables, deployed through the same CI/CD pipeline. #PostgreSQL #BackendDevelopment #DevOps #CICD #Serverless #Scheduling #SystemDesign #APIs #Automation

🚀 How do you prevent cascading failures when an external API goes down? Enter the Circuit Breaker Pattern! 🛡️ In microservices, depending on external services can be risky. If a downstream API times out or fails, it can exhaust your system's resources and take your entire application down with it. To solve this, I recently built a Spring Boot application demonstrating the Circuit Breaker pattern using Resilience4j. I’ve attached a diagram breaking down the architecture, states, and configurations! 🧠👇 Here is a look at how the application is configured to handle failures gracefully: ✅ The States: 1. CLOSED (Normal): Requests flow to the external WeatherService. The system monitors the last 5 calls (Sliding Window). 2. OPEN (Tripped): If the failure rate hits 50%, or if calls take longer than 2 seconds, the circuit trips! Requests are instantly routed to a Fallback Method, returning a default message instead of crashing. 3. HALF-OPEN (Recovery): After 10 seconds, the circuit allows exactly 3 test calls through to check if the downstream API has recovered. If successful, it closes again! By implementing a simple @CircuitBreaker annotation and configuring my application.properties, the system automatically fails fast and ensures a smooth user experience—even when things break behind the scenes. 💡 💻 Check out the full source code on my GitHub: 🔗 https://lnkd.in/g--Xf87k Have you used Resilience4j or similar fault-tolerance libraries in your projects? Let me know your thoughts in the comments! 👇 #SpringBoot #Java #Microservices #Resilience4j #SoftwareArchitecture #CircuitBreaker #BackendDevelopment #FaultTolerance #JavaDeveloper #Coding