Avoid Blocking APIs with Async Processing in Spring Boot

Day 7 — The API Latency Trap Your API feels fast locally… but suddenly takes 1.2 seconds in production. Here’s what’s really happening 👇 You’re calling multiple external services: • User API • Order API • Payment API Each takes ~400 ms. User user = userClient.getUser(id); Order order = orderClient.getOrder(id); Payment payment = paymentClient.getPayment(id); Looks clean, right? But these calls are sequential. 👉 Total latency = 400 + 400 + 400 = 1200 ms This works fine in testing… but in production, it kills user experience. ⸻ ✅ The Fix: Parallel Calls CompletableFuture<User> userFuture = CompletableFuture.supplyAsync(() -> userClient.getUser(id)); CompletableFuture<Order> orderFuture = CompletableFuture.supplyAsync(() -> orderClient.getOrder(id)); CompletableFuture<Payment> paymentFuture = CompletableFuture.supplyAsync(() -> paymentClient.getPayment(id)); CompletableFuture.allOf(userFuture, orderFuture, paymentFuture).join(); User user = userFuture.join(); Order order = orderFuture.join(); Payment payment = paymentFuture.join(); 👉 Latency drops from 1200 ms → ~400 ms ⸻ 💡 Senior-Level Insight • Don’t rely on default thread pools → use custom executors • Add timeouts + fallbacks (Resilience4j) • Prefer WebClient (non-blocking) for scalable systems ⸻ 🎯 The Lesson Sequential API calls are silent performance killers. Parallelism is not an optimization — it’s a requirement. ⸻ If your service depends on multiple APIs… fix this before production exposes it. ⸻ #BackendDevelopment #Java #SpringBoot #Microservices #SystemDesign #Performance #APIs #DistributedSystems

🚀 Understanding HTTP Status Codes in REST APIs While building APIs, one important thing is not just sending data… 👉 It’s also about sending the right response status. These are called HTTP Status Codes. They help the client understand what happened with the request. 🔹 Common Status Codes ✔ 200 – OK Request was successful Example: Data fetched successfully ✔ 201 – Created New resource created Example: User registered successfully ✔ 400 – Bad Request Invalid input from client Example: Missing or wrong data ✔ 404 – Not Found Requested resource not found Example: User ID does not exist ✔ 500 – Internal Server Error Something went wrong on the server 🔹 Example in Spring Boot @GetMapping("/users/{id}") public ResponseEntity<User> getUser(@PathVariable Long id) { User user = userService.findById(id); return ResponseEntity.ok(user); } If user is not found, we can return: return ResponseEntity.status(HttpStatus.NOT_FOUND).build(); 💡 Why Status Codes are important ✔ Help frontend understand response ✔ Improve API communication ✔ Make APIs more professional ✔ Very common in interviews Understanding status codes helped me connect concepts like exception handling, validation, and API design. #Java #SpringBoot #BackendDevelopment #APIDesign #Learning

Day 24. My API was fast. Until it wasn't. I had this: return ResponseEntity.ok(userRepository.findAll()); 10 users in development. Works instantly. Feels perfect. Then production happened: → 50,000 users in the database → One API call loads everything → Response time: 40ms → 8 seconds → Memory spikes → API crashes That's not a performance issue. That's a design mistake. And it was there from day one. I just couldn't see it yet. That's when it clicked: Your API should never decide how much data to return. The client should. So I added pagination. (see implementation below 👇) What changed: → Performance — stable response time → Scalability — works at 100 or 100,000 rows → Stability — no memory spikes The hard truth: → findAll() works in tutorials → It breaks in production → Pagination is not an optimization — it's a requirement Fetching data is easy. Controlling how much you fetch is what makes your API scalable. Are you still using findAll() in production? 👇 Drop it below #SpringBoot #Java #BackendDevelopment #Performance #JavaDeveloper

APIs started making sense to me when I stopped memorizing… and started understanding the flow 👇 At a basic level, an API is just a way for systems to communicate. But what actually happens when you hit an API? Let’s break it down: 1️⃣ Client sends a request Example: GET /users/1 2️⃣ Request reaches the server → Routed to the correct controller 3️⃣ Business logic runs → Service layer processes the request 4️⃣ Database interaction → Fetch / update data 5️⃣ Response is returned → Usually JSON So the real flow is: 👉 Client → Controller → Service → Database → Response What helped me most was understanding this: • APIs are not just endpoints • They are structured layers working together Also, things started clicking when I focused on: • HTTP methods (GET, POST, PUT, DELETE) • Status codes (200, 404, 500) • Request & response structure Still learning, but understanding this flow made backend development much clearer. If you're learning APIs, focus on the flow — not just the syntax. #BackendDevelopment #APIs #Java #SpringBoot #WebDevelopment #Developers #LearningInPublic

Ever wondered why your API sometimes screams at you with random 3-digit numbers? Let me simplify this for you. HTTP Status Codes — the language your server speaks when it cannot talk to you directly. Every backend dev who skips learning these properly ends up googling them at 2 AM during production incidents. Do not be that person. Here is what those numbers actually mean: → 2xx — Everything went well Server received your request. Processed it. Sent back the goods. → 200 OK — classic success → 201 Created — you built something new on the server → 202 Accepted — request is in, but processing is still happening Know which one to return in your REST APIs. They are NOT interchangeable. → 3xx — You are being redirected The resource moved. Server is politely pointing you elsewhere. → 301 = gone forever, update your bookmarks → 302 = temporarily elsewhere, come back later → 304 = nothing changed, use your cached version This is where SEO and API versioning decisions live. → 4xx — You made a mistake Stop blaming the server. The problem is on the client side. → 400 = your request is malformed → 401 = prove who you are first → 403 = I know who you are, but you cannot enter → 404 = this thing does not exist → 405 = wrong HTTP method, read the docs → 408 = you took too long, connection dropped Most debugging time in backend dev lives right here. → 5xx — The server made a mistake Now it is not your code. It is the infrastructure sweating. → 500 = something broke on the server, no specifics → 501 = this feature is not built yet → 502 = bad response from an upstream server → 503 = server is overwhelmed or down → 504 = upstream server took too long to respond This is the category that triggers incident alerts and ruins weekends. 18 status codes. One cheat sheet. Zero excuses for not knowing these. Whether you are building REST APIs, debugging microservices, or just cracking Java backend interviews - these codes come up everywhere. Screenshot this. Pin it somewhere visible. You will need it sooner than you think #HTTPStatusCodes #BackendDevelopment #Java #SpringBoot #SystemDesign #SoftwareEngineering #DSA #WebDevelopment #JavaDeveloper #CodingTips

Most REST APIs aren't actually REST. They're just HTTP with JSON. After years of building Java-based REST services, I've seen this pattern more times than I can count — endpoints that call themselves "RESTful" but don't go beyond basic HTTP calls. That's where the Richardson Maturity Model (RMM) becomes a real eye-opener. Leonard Richardson broke REST maturity into 4 levels: 🔹 Level 0 — The Swamp of POX One endpoint, one HTTP method (usually POST), everything tunneled through it. Think old-school SOAP services. No real REST here. 🔹 Level 1 — Resources You start modeling your domain as resources (/orders, /users). But you're still not leveraging HTTP properly. 🔹 Level 2 — HTTP Verbs Now you're using GET, POST, PUT, DELETE meaningfully. Status codes like 201, 404, 409 are used correctly. This is where most production Java APIs live — and where many teams stop. 🔹 Level 3 — HATEOAS Hypermedia as the Engine of Application State. Responses include links that tell the client what it can do next. The API becomes self-discoverable. In Spring, this is achievable with Spring HATEOAS out of the box. The honest truth from the field: Most enterprise systems sit comfortably at Level 2 — and that's often good enough. But understanding Level 3 makes you design better APIs even if you don't fully implement HATEOAS. It forces you to think: "What can the client do after this response?" That mindset shift alone has improved how I design resource relationships, pagination links, and error responses in every Java project I've worked on. Where does your API sit on the RMM? Drop a level below 👇 #Java #RestAPI #SpringBoot #SoftwareEngineering #APIDesign #BackendDevelopment #HATEOAS #WebServices #JavaDeveloper #CleanCode

🌐 REST APIs: Simple in Theory, Tricky in Reality Creating APIs is easy. Designing GOOD APIs is hard. Here’s what I learned: ❌ Bad: /getUserData ✅ Good: /users/{id} ❌ Returning everything ✅ Returning only required data (DTO) ❌ Ignoring status codes ✅ Using proper HTTP responses (200, 404, 500) Small improvements = Professional APIs 🚀 What’s one API mistake you’ve seen often? #RESTAPI #Java #SpringBoot #Backend

Your transaction works perfectly… ✅ Until you call 𝗮𝗻𝗼𝘁𝗵𝗲𝗿 𝗺𝗲𝘁𝗵𝗼𝗱 inside it. Suddenly things behave… differently. Why? 𝗣𝗿𝗼𝗽𝗮𝗴𝗮𝘁𝗶𝗼𝗻. If you’re using `@Transactional` and not thinking about propagation, you’re basically saying: “Spring… you decide.” So what is propagation? It defines how a transaction behaves when one method calls another. Simple idea. But huge impact. Let’s break it down with real-world scenarios 🔹 REQUIRED (default) “Join if exists, else create” 💡 Example: Placing an order → Payment service called Both run in the "same transaction". If payment fails → everything rolls back. 🔹 REQUIRES_NEW “Always start fresh” 💡 Example: Order fails ❌ But you still want to "log the failure" Logging runs in a separate transaction → it gets saved ✅ 🔹 SUPPORTS “Join if exists, else run without transaction” 💡 Example: Fetching optional audit data Transaction or not… it doesn’t care. 🔹 NOT_SUPPORTED “Run without transaction” 💡 Example: Heavy read operation where transaction overhead is unnecessary Suspends existing transaction ⏸️ 🔹 MANDATORY “Transaction must exist” 💡 Example: Critical financial operation If no transaction → throw error 🚨 🔹 NEVER “Transaction must NOT exist” 💡 Example: A method that should never be part of a transaction If one exists → exception 💥 🔹 NESTED “Transaction inside a transaction” 💡 Example: Partial rollback scenario Inner transaction fails → outer can still continue Here’s the real insight Most bugs in transaction handling don’t come from syntax… They come from 𝘄𝗿𝗼𝗻𝗴 𝗽𝗿𝗼𝗽𝗮𝗴𝗮𝘁𝗶𝗼𝗻 choices. Using `@Transactional` is easy. Using it correctly is what makes you a solid backend developer. Next time you add `@Transactional`, don’t stop there… Ask: “How should this transaction behave?” #CoreJava #SpringBoot #JavaDeveloper #Transactional #BackendDevelopment #SoftwareEngineering #Developers #Programming #Developers #RDBMS #SQL #JPA #Hibernate #Database #Microservices #aswintech #SystemDesign

Ever wondered why your API sometimes screams at you with random 3-digit numbers? Let me simplify this for you. HTTP Status Codes — the language your server speaks when it cannot talk to you directly. Every backend dev who skips learning these properly ends up googling them at 2 AM during production incidents. Do not be that person. Here is what those numbers actually mean: → 2xx — Everything went well Server received your request. Processed it. Sent back the goods. → 200 OK — classic success → 201 Created — you built something new on the server → 202 Accepted — request is in, but processing is still happening Know which one to return in your REST APIs. They are NOT interchangeable. → 3xx — You are being redirected The resource moved. Server is politely pointing you elsewhere. → 301 = gone forever, update your bookmarks → 302 = temporarily elsewhere, come back later → 304 = nothing changed, use your cached version This is where SEO and API versioning decisions live. → 4xx — You made a mistake Stop blaming the server. The problem is on the client side. → 400 = your request is malformed → 401 = prove who you are first → 403 = I know who you are, but you cannot enter → 404 = this thing does not exist → 405 = wrong HTTP method, read the docs → 408 = you took too long, connection dropped Most debugging time in backend dev lives right here. → 5xx — The server made a mistake Now it is not your code. It is the infrastructure sweating. → 500 = something broke on the server, no specifics → 501 = this feature is not built yet → 502 = bad response from an upstream server → 503 = server is overwhelmed or down → 504 = upstream server took too long to respond This is the category that triggers incident alerts and ruins weekends. 18 status codes. One cheat sheet. Zero excuses for not knowing these. Whether you are building REST APIs, debugging microservices, or just cracking Java backend interviews - these codes come up everywhere. Screenshot this. Pin it somewhere visible. You will need it sooner than you think. Comment HTTP and I'll DM you the full HTTP Status Codes PDF → completely free. Follow Narendra K. for more Java | Backend Development | DSA content delivered straight to your feed. #HTTPStatusCodes #BackendDevelopment #Java #SpringBoot #SystemDesign #SoftwareEngineering #DSA #WebDevelopment #JavaDeveloper #CodingTips

Users double-click. Networks retry. Payment gateways resend. If your API isn’t idempotent… you may create duplicate data. Many backend APIs look like this: @PostMapping("/orders") public Order createOrder(@RequestBody OrderRequest req){ return orderService.create(req); } Seems fine. But what happens if the same request is sent twice? You may create: • duplicate orders • duplicate payments • inconsistent data ⸻ ❌ Without Idempotency Client (retry) ↓ POST /orders ↓ Order created twice Bad for payments and transactions. ⸻ ✅ With Idempotency Key Client sends: Idempotency-Key: 12345 Server logic: if(keyExists(key)){ return existingResponse; } Now duplicate request → same response. ⸻ 🧠 Where This Matters Most Use idempotency for: • Payment APIs • Order creation • Booking systems • External integrations ⸻ 💡 Expert Rule GET → naturally idempotent PUT → idempotent POST → must be designed carefully ⸻ ⭐ Lesson Good backend APIs handle retries safely. Great backend APIs prevent duplicate side effects. ⸻ Day 19 of becoming production-ready with Spring Boot. Question: Do your APIs handle duplicate requests? ⸻ #Java #SpringBoot #BackendEngineering #APIDesign #SoftwareArchitecture