Global Exception Handling in Spring Boot with @ControllerAdvice

⚠️ Hot Reload in Spring Boot Isn’t Magic. It’s ClassLoader Isolation. When you change code and see: 👉 App restarts in seconds 👉 No full JVM restart What’s really happening? 1️⃣ Two ClassLoaders — The Core Idea Spring Boot DevTools splits your app into: Base ClassLoader   → dependencies (stable) Restart ClassLoader → your application code (changing) 2️⃣ Why This Matters Dependencies (like Spring, Hibernate): Loaded once Heavy to reload Rarely change Your code: Changes frequently Needs fast reload So only your code is reloaded. 3️⃣ What Happens on Code Change You modify a .class file DevTools detects change (file watcher) Discards Restart ClassLoader Creates a new one Reloads your classes Base ClassLoader stays untouched 4️⃣ Why It’s Faster Than Full Restart Without DevTools: JVM restarts All classes reloaded Framework reinitialized With DevTools: Only your classes reload Dependencies reused Startup drastically reduced 5️⃣ What Actually Gets Restarted? Spring ApplicationContext Beans created again Config reloaded But: 👉 JVM process stays alive 👉 Core libraries remain loaded 6️⃣ Common Gotcha (Very Important) Static state survives in Base ClassLoader. Example: static Map cache = new HashMap(); If loaded by base loader: It won’t reset after reload Leads to weird bugs 7️⃣ Why Some Changes Don’t Reload DevTools won’t reload when: Dependency JAR changes Config outside classpath changes Native resources updated Requires full restart 8️⃣ Comparison With Other Tools Tool Approach DevTools ClassLoader restart JRebel Bytecode rewriting HotSwap Limited JVM replacement DevTools doesn’t “reload classes” It replaces the ClassLoader that loaded them #Java #SpringBoot #JVM #ClassLoader #HotReload #BackendEngineering #SoftwareEngineering #LearnInPublic

File Uploads and Retrieval in Spring Boot Master file management in modern web applications by exploring File Uploads and Retrieval in Spring Boot. Handling binary data is a core requirement for enterprise systems, and this guide provides a deep dive into building a robust solution using REST controllers and the MultipartFile interface. Following a "core-to-shell" approach, you’ll learn to integrate foundational Java NIO operations with high-level Spring APIs to create a seamless bridge between raw disk storage and your frontend. Discover how to implement secure uploads and efficient file fetching while maintaining a clean, scalable microservices architecture. => Multipart Management: Efficiently process file streams with Spring Boot. => Java NIO Mastery: Use modern I/O for high-performance file handling. => RESTful Fetch: Implement endpoints for secure content retrieval. https://lnkd.in/gyQvP5QA #SpringBoot #spring #springframework #springbootdeveloper #Maven #Java #java #JAVAFullStack #RESTAPI #Microservices #BackendDev #JavaNIO #FileUpload #WebDevelopment #CodingTutorial #codechallenge #programming #CODE #Coding #code #programmingtips

💡 How many of us REALLY know how "@Transactional" works in Spring Boot? Most developers use "@Transactional" daily… But under the hood, there’s a lot more happening than just "auto rollback on exception". Let’s break it down 👇 🔹 What is "@Transactional"? It’s a declarative way to manage database transactions in Spring. Instead of manually writing commit/rollback logic, Spring handles it for you. --- 🔍 What actually happens behind the scenes? 1️⃣ Spring creates a proxy object around your service class 2️⃣ When a method annotated with "@Transactional" is called → it goes through the proxy 3️⃣ The proxy: - Opens a transaction before method execution - Commits if everything succeeds ✅ - Rolls back if a runtime exception occurs ❌ --- ⚙️ Execution Flow Client → Proxy → Transaction Manager → Target Method → DB --- 🚨 Important Gotchas ❗ Works only on public methods ❗ Self-invocation (method calling another method inside same class) will NOT trigger transaction ❗ By default, only unchecked exceptions trigger rollback ❗ Uses AOP (Aspect-Oriented Programming) --- 🧠 Advanced Concepts ✔ Propagation (REQUIRED, REQUIRES_NEW, etc.) ✔ Isolation Levels (READ_COMMITTED, SERIALIZABLE) ✔ Transaction Manager (PlatformTransactionManager) ✔ Lazy initialization & session handling --- 🔥 Example @Service public class PaymentService { @Transactional public void processPayment() { debitAccount(); creditAccount(); // If credit fails → debit will rollback automatically } } --- ✨ Pro Tip Understanding "@Transactional" deeply can save you from: - Data inconsistencies - Hidden bugs - Production failures --- 👉 Next time you use "@Transactional", remember — you're not calling a method… you're triggering a proxy-driven transaction lifecycle! #SpringBoot #Java #BackendDevelopment #Microservices #TechDeepDive #Learning

I was debugging a backend issue recently in a Java service. At first nothing looked wrong. No errors, no obvious problems. But something was off. After checking a bit more, it turned out to be a small mismatch between the data model and the repository. The code worked fine in most cases, but not with certain data. Fixing it was simple. Finding it was not. Sometimes the problem is not complex. It’s just hidden in small details. #Java #BackendEngineering #Debugging #SpringBoot

In production Spring Boot services, scattered try-catch blocks create inconsistent API behavior. A better approach is centralized handling: ```@RestControllerAdvice public class GlobalExceptionHandler {   @ExceptionHandler(ResourceNotFoundException.class)   public ResponseEntity<ErrorResponse> handleNotFound(ResourceNotFoundException ex) {     return ResponseEntity.status(HttpStatus.NOT_FOUND)         .body(new ErrorResponse("RESOURCE_NOT_FOUND", ex.getMessage()));   }   @ExceptionHandler(MethodArgumentNotValidException.class)   public ResponseEntity<ErrorResponse> handleValidation(MethodArgumentNotValidException ex) {     return ResponseEntity.status(HttpStatus.BAD_REQUEST)         .body(new ErrorResponse("VALIDATION_ERROR", "Invalid request payload"));   }   @ExceptionHandler(Exception.class)   public ResponseEntity<ErrorResponse> handleGeneric(Exception ex) {     return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)         .body(new ErrorResponse("INTERNAL_ERROR", "Unexpected error occurred"));   } }``` Benefits we observed: - Consistent contract for error payloads - Cleaner controllers/services - Accurate HTTP semantics (400, 404, 409, 500) - Better observability and incident response A strong error model is part of API design, not just exception handling. #SpringBoot #Java #Microservices #API #SoftwareEngineering #Backend

🚀 Improving API Performance using Multi-Threading in Spring Boot In today’s fast-paced systems, API latency directly impacts user experience and business revenue. I recently built a small project to understand how synchronous vs asynchronous processing affects performance in a microservices-like setup. 🔍 Use Case A service needs to fetch: * Product details * Price * Inventory from different sources (simulated as separate services). --- ❌ Problem with Synchronous Approach All calls run in a single thread: * Product → Price → Inventory * Each call waits for the previous one * Total time ≈ 6+ seconds (due to delays) --- ✅ Solution: Asynchronous with Multi-Threading Using Java’s CompletableFuture, we run all calls in parallel: * Product → Thread 1 * Price → Thread 2 * Inventory → Thread 3 ⏱ Result: Total time reduced to ~2 seconds --- 💡 Key Learning * Don’t block a single thread for independent tasks * Use parallel execution for IO-bound operations * `CompletableFuture` is a simple and powerful way to achieve concurrency in Spring Boot --- 📊 Performance Comparison * Sync: ~6.7s * Async: ~2.1s --- 📌 Takeaway Whenever your API aggregates data from multiple services, go async to reduce latency and improve scalability --- I’ll be sharing: 👉 Code breakdown 👉 Interview questions from this concept 👉 Real-world improvements (thread pools, error handling) Stay tuned 🔥 #Java #SpringBoot #BackendDevelopment #Microservices #Multithreading #Performance #APIDesign

📘 Part 2: Deep Dive — API Performance Optimization using Multithreading In my previous post, I showed how switching from synchronous → asynchronous execution reduced API response time from ~6.7s to ~2.1s 🚀 Today, I’m breaking that down into a structured learning module you can actually revise and apply. 🧠 Problem Recap You have an API that aggregates data from multiple sources: Product Service Price Service Inventory Service ❌ In a synchronous flow, everything runs in a single thread: → Total Time = T1 + T2 + T3 → Result: Slow & blocking ⚡ Solution: Multithreading with CompletableFuture Instead of waiting for each call: ✅ Run them in parallel threads → Total Time = max(T1, T2, T3) 🔑 Core Implementation Idea CompletableFuture<Product> productFuture = CompletableFuture.supplyAsync(() -> productService.findById(id)); CompletableFuture.allOf(productFuture, priceFuture, inventoryFuture).join(); ✔ Parallel execution ✔ Non-blocking ✔ Faster response 📊 Performance Comparison Approach Time Taken Synchronous ~6.75 sec Asynchronous ~2.1 sec 🏗 Architecture Used Controller → Facade → Service → Repository → DB 👉 Facade layer acts as an orchestrator (important design pattern) ⚠️ When to Use This? Use async when: ✔ Multiple independent API calls ✔ IO-bound operations ✔ Aggregation APIs Avoid when: ❌ Tasks depend on each other ❌ CPU-heavy processing 💡 Real-World Best Practices Use custom thread pools (don’t rely on defaults) Handle failures with .exceptionally() Add timeouts for external calls Monitor using metrics (Micrometer / Prometheus) 🎯 Key Takeaway 👉 “Don’t block a thread when you don’t have to.” Parallel execution is one of the simplest yet most powerful optimizations in backend systems. Next post I’ll cover: 🔥 Common mistakes with CompletableFuture 🔥 How to avoid thread pool issues 🔥 Production-grade improvements Follow along if you’re into backend performance 👇 #Java #SpringBoot #Multithreading #BackendEngineering #Microservices #PerformanceOptimization

📘 Part 3: CompletableFuture vs @Async — Which Async Approach Should You Use? In my previous posts, we improved API performance using multithreading and reduced response time significantly 🚀 Now let’s address a question that often comes up: 👉 “Why didn’t i use @Async?” Short answer: Because not all async approaches are built for the same problem. 🧠 Two Ways to Handle Async in Spring Boot 1️⃣ CompletableFuture (Java-level control) CompletableFuture.supplyAsync(...) ✔ You control thread execution ✔ You control how tasks are combined (allOf, join) ✔ Ideal for orchestrating multiple parallel calls 👉 Perfect for: Aggregation APIs (Product + Price + Inventory) 2️⃣ @Async (Spring abstraction) @Async public CompletableFuture<Product> getProduct(Long id) { return CompletableFuture.completedFuture(productService.findById(id)); } ✔ Spring manages threads ✔ Cleaner and simpler code ❌ Less control over execution flow 👉 Perfect for: Background tasks (email, logging, notifications) ⚖️ Key Difference Capability|CompletableFuture | @Async ->Thread - control . |High | Low ->Result - composition. |Excellent | Limited - Orchestration. ->logic | Strong | Weak ⚠️ Important Insight (Most Developers Miss This) If you use: CompletableFuture.supplyAsync(...) without providing an executor… 👉 It uses ForkJoinPool.commonPool() That means: ❌ Shared global thread pool ❌ Can become a bottleneck under load ❌ Harder to control performance ✅ Production-Grade Approach Combine both worlds: @Autowired private Executor taskExecutor; CompletableFuture<Product> productFuture = CompletableFuture.supplyAsync(() -> productService.findById(id), taskExecutor); ✔ Controlled thread pool ✔ Better scalability ✔ Stable under high traffic 🔥 When to Use What? Use CompletableFuture when: ✔ Multiple independent API calls ✔ Need to combine results ✔ Building high-performance APIs Use @Async when: ✔ Fire-and-forget operations ✔ Background processing ✔ No need for result orchestration 🎯 Key Takeaway 👉 “Async is not just about making things parallel — it’s about choosing the right control model.” CompletableFuture → Precision + orchestration @Async → Simplicity + delegation 🚀 Final Verdict ✔ Not using @Async in the previous example is intentional ✔ For aggregation APIs, CompletableFuture is the better choice Next post I’ll cover: 🔥 Common mistakes with CompletableFuture 🔥 Thread pool issues that silently degrade performance 🔥 How to make this truly production-ready Follow along if you're serious about backend performance 👇 #Java #SpringBoot #Multithreading #BackendEngineering #Microservices #PerformanceOptimization

📘 Part 4: Async POST APIs — Can You? Yes. Should You? Depends. We optimized GET APIs using parallel calls 🚀 But POST/updates are different. 👉 Writes are about consistency, ordering, and failure handling — not just speed. 🧠 Two Async Patterns for POST 1️⃣ Fire-and-Forget (Most Common) API responds immediately, work continues in background. Use cases: Order processing Emails/notifications File/image processing Flow: POST → 202 Accepted → background processing 👉 Best implemented using @Async @Async public void processOrder(OrderRequest request) { saveOrder(request); callPaymentService(); } ✔ Fast response ✔ Simple ✔ Works well for non-critical flows 2️⃣ Parallel Writes (Advanced ⚠️) One request triggers multiple updates in parallel: DB update Payment call Inventory update Using CompletableFuture CompletableFuture.runAsync(() -> updateDatabase()); CompletableFuture.runAsync(() -> callPayment()); Sounds good… but risky. ⚠️ What Can Go Wrong? ❗ Partial failure (DB success, payment fails = inconsistent system) ❗ Transactions break @Transactional doesn’t work across threads 👉 No rollback, no atomicity 🧠 What Real Systems Do Instead of raw async → use Event-Driven Architecture Flow: POST → Save (PENDING) → Publish event → Consumers process Tools: Kafka RabbitMQ ✔ Reliable ✔ Scalable ✔ Handles failure better 💡 Key Insight GET → optimize speed POST → optimize correctness 🎯 Final Takeaway Use: @Async → background tasks CompletableFuture → simple parallel work Events (Kafka/RabbitMQ) → critical workflows 👉 Async is easy. Correct async is hard. #Java #SpringBoot #BackendEngineering #SystemDesign #Microservices #PerformanceOptimization

📘 Part 5: Choosing the Right Concurrency Model (Not Just CompletableFuture) In the previous posts, i used CompletableFuture to improve API performance 🚀 But here’s a deeper question: 👉 Was that the only option? Short answer: No. Better answer: You should know all options—and choose intentionally. 🧠 The Real Engineering Mindset When solving: 👉 “Fetch data from multiple sources concurrently” There isn’t just one way. There’s a spectrum of concurrency models. 1️⃣ Manual Threads ❌ (Outdated) new Thread(() -> fetchProduct()).start(); Why this is avoided: No thread pooling No lifecycle control Hard to scale/debug 👉 You’ll almost never see this in production code 2️⃣ ExecutorService (Foundation Level) ExecutorService executor = Executors.newFixedThreadPool(3); Future<Product> product = executor.submit(() -> fetchProduct()); product.get(); ✔ Full control over threads ✔ Industry-proven But: ❌ Blocking (get() waits) ❌ Hard to combine multiple results ❌ Verbose 👉 Great for understanding core Java concurrency 3️⃣ CompletableFuture ✅ (Modern Standard) CompletableFuture.supplyAsync(() -> fetchProduct()); ✔ Non-blocking style ✔ Easy composition ( allOf , thenCombine ) ✔ Cleaner, readable code ⚠️ Needs custom executor in production 👉 This is why most real-world APIs use it 4️⃣ Spring @Async (Abstraction) @Async public CompletableFuture<Product> getProduct() { ... } ✔ Simple ✔ Spring manages threads ❌ Limited control for orchestration 👉 Best for background tasks, not aggregation APIs 5️⃣ Reactive Programming ⚡ (Advanced) Using WebFlux / Reactor: Mono.zip(productMono, priceMono, inventoryMono) // Mono.zip() is a reactive operator from Project Reactor (used in Spring WebFlux) that lets you combine multiple asynchronous results into one. Think of it as the reactive equivalent of: 👉 CompletableFuture.allOf(...).join() ✔ Fully non-blocking ✔ Handles massive concurrency But: ❌ Steep learning curve ❌ Debugging is harder 👉 Used in high-scale systems (think Netflix-level traffic) 🧠 The Insight Most People Miss 👉 CompletableFuture is not magic Under the hood, it still uses a thread pool (ExecutorService) So you’re not replacing it—you’re using a higher-level abstraction 💡 Practical Rule “How would you improve API performance?” A strong answer i follow: 👉 “There are multiple approaches like ExecutorService, CompletableFuture, or reactive programming. For this case, I’d choose CompletableFuture because it provides non-blocking orchestration with better readability and maintainability.” 🎯 Final Takeaway Manual threads → avoid ExecutorService → foundational CompletableFuture → best balance (most common) @Async → background tasks Reactive → high-scale systems 👉 Good developers know one approach 👉 Strong engineers know why they chose it Follow along if you want to think like a senior backend engineer 👇 #Java #SpringBoot #BackendEngineering #SystemDesign #Microservices #PerformanceOptimization