Simplifying Backend Logic for Better Performance

One of the most abused annotations in Spring is @Transactional. People treat it like a “wrap everything and forget” switch. I’ve seen methods like this: 👉 save to DB 👉 call external payment API 👉 send email 👉 call another microservice 👉 update DB again All inside ONE transaction. Looks clean. Feels safe. It’s not. Because the moment you mix DB + external calls inside a transaction, things start getting messy: ⚠️ external APIs are slow ⚠️ transactions stay open longer (locks, performance issues) ⚠️ if API fails → DB rolls back, but external system doesn’t ⚠️ debugging becomes painful Now you have inconsistent systems and no clear recovery path. The better way? Keep @Transactional boring. ✔️ only DB operations inside ✔️ keep it short ✔️ do external calls before or after ✔️ think about failure scenarios explicitly @Transaction is not a safety net. It’s a boundary. Use it wrong → hidden bugs Use it right → stable systems Learned this the hard way 🙂 #Java #SpringBoot #BackendEngineering #SystemDesign #Microservices #CodeQuality

Spring Boot in Real Projects — Day 19 We already know how APIs return data. But what happens when your application grows and starts handling hundreds or even thousands of tasks daily whether from a single user or many users? For example: User1 → 50 tasks   User2 → 120 tasks   User3 → 300 tasks   It's simple to fetch data for user-1 and next user-2 with 120 tasks gets heavy to fetch and for the next user-3 its hard to fetch and the API response may gets slow, to solve this Pagination & Sorting come in What is Pagination? Pagination is the process of dividing data into smaller chunks (pages) and fetching only the required portion instead of loading everything at once. What is Sorting? Sorting allows us to order data based on a specific field like createdAt, title, etc. Flow Client → Controller → Pageable → Repository → Database (applies LIMIT, OFFSET, ORDER BY) → Returns Page → Response to Client #SpringBoot #Java #BackendDevelopment #Pagination #APIDesign #SoftwareEngineering

🚨 Fetching all data from DB is a silent performance killer I once saw an API fetching 50,000 records in one go. 💥 Result: High memory usage Slow response Occasional crashes ✅ Fix: Used pagination: Pageable pageable = PageRequest.of(page, size); 💡 Bonus: Added sorting + limit control from API 💡 Takeaway: Never trust frontend to “handle large data” Backend should enforce limits. #Java #SpringBoot #BackendDevelopment #SoftwareEngineering  #Microservices #JPA #RESTAPI  #DeveloperLife #CareerGrowth

#Post6 In the previous posts, we built basic REST APIs step by step. But what happens when something goes wrong? 🤔 Example: User not found Invalid input Server error 👉 By default, Spring Boot returns a generic error response. But in real applications, we need proper and meaningful error handling. That’s where Exception Handling comes in 🔥 Instead of handling exceptions in every method, Spring provides a better approach using @ControllerAdvice 👉 It allows us to handle exceptions globally Example: @ControllerAdvice public class GlobalExceptionHandler { @ExceptionHandler(Exception.class) public String handleException(Exception ex) { return ex.getMessage(); } } 💡 Why use this? • Centralized error handling • Cleaner controller code • Better API response Key takeaway: Use global exception handling to manage errors in a clean and scalable way 🚀 In the next post, we will create custom exceptions for better control 🔥 #Java #SpringBoot #BackendDevelopment #RESTAPI #LearnInPublic

𝗔𝗳𝘁𝗲𝗿 𝗿𝗲𝘃𝗶𝗲𝘄𝗶𝗻𝗴 𝗵𝘂𝗻𝗱𝗿𝗲𝗱𝘀 𝗼𝗳 𝗣𝗥𝘀, 𝗜 𝗸𝗲𝗲𝗽 𝘀𝗲𝗲𝗶𝗻𝗴 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗶𝘀𝘀𝘂𝗲. The developer did everything right: clean code, proper repository, correct relationships. And yet, the application was making 𝟱𝟬 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝗾𝘂𝗲𝗿𝗶𝗲𝘀 to display a single page. Nobody noticed. Until production. This is the N+1 problem. In simple terms: instead of 1 query, your app makes 1 + N, one for each item. You don't see it in your code. You see it in your logs: 1 query for orders, then 1 query per customer. 500 orders = 501 queries. The reflex fix? Switch to EAGER loading. That's often the wrong answer. The real fix is understanding 𝘄𝗵𝗮𝘁 𝘆𝗼𝘂'𝗿𝗲 𝗹𝗼𝗮𝗱𝗶𝗻𝗴 𝗮𝗻𝗱 𝘄𝗵𝗲𝗻. Need the data always? use JOIN FETCH Need it sometimes? use @EntityGraph Need full control? use DTO query N+1 is not a JPA bug. It's a judgment problem: the difference between code that works locally and systems that perform in production. I've attached a visual breakdown of these 3 approaches with real examples. Have you ever shipped something that worked perfectly in dev… but broke in production? #Java #SpringBoot #JPA #Hibernate #Backend #Performance #SoftwareEngineering

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

Everything failed… but the database still got updated 🙃. Recently, while working on a feature in Spring Boot project, I used @Transactional annotation assuming it would rollback the entire operation if something failed. But during testing, I noticed something strange, even after an exception, some data was still getting saved. That’s when I started digging deeper. I realized that @Transactional doesn’t always behave the way we expect: - It rolls back only for unchecked exceptions (RuntimeException) by default. - If the method call happens within the same class, it might not work due to proxy behavior. - Catching exceptions without rethrowing can prevent rollback. In my case, I was catching the exception and not rethrowing it. So Spring thought everything was fine and committed the transaction. Once I fixed that, the rollback worked as expected. Annotations make things easier… but understanding how they actually work makes you a better developer. #Java #SpringBoot #BackendDevelopment #Transactional #LearningInPublic #SoftwareEngineering #Database #SpringJPA #DataManagement

Difference between @Component, @Service, and @Repository in Spring Today I realized something interesting while working with Spring. We use @Component, @Service, and @Repository almost daily. For a long time, I thought — aren’t they all the same? Technically yes… but architecturally, no. All three tell Spring to create a bean. But the real difference is the intent they communicate in our code. All are components, but: • @Component → Generic bean • @Service → Business logic • @Repository → Database layer with exception handling Using the right annotation improves clean architecture, readability, and maintainability. Nothing changes in how Spring creates the bean. But everything changes in how developers understand the structure of the application. That small clarity makes a big difference in clean architecture and maintainability. Sometimes, it’s not about what the code does — it’s about what the code communicates. #SpringBoot #Java #CleanCode #BackendDevelopment #SoftwareEngineering #Learning #SpringBoot #Java #Annotations #BackendDevelopment #CleanCode #SoftwareEngineering #Microservices

Inside a Spring Boot Request — What really happens? Most developers stop at writing controllers. But real engineering starts when you understand what happens under the hood. I came across this deep dive by Coding Shuttle and it perfectly breaks down the full request lifecycle Complete flow (simplified): 1️⃣ Client sends HTTP request → reaches embedded server (Tomcat) 2️⃣ Thread from pool is assigned (thread-per-request model) 3️⃣ Request passes through Security Filter Chain (authentication happens) 4️⃣ DispatcherServlet routes request → correct controller 5️⃣ Controller → Service → Repository (business + DB logic) 6️⃣ Transaction starts → DB connection taken from pool 7️⃣ Query executes → response object created 8️⃣ Response serialized (JSON via Jackson) 9️⃣ Thread released back to pool Key insights most developers ignore: 👉 Everything runs on one thread (unless you break it with async/reactive) 👉 Security & Transactions are ThreadLocal-bound 👉 DB connections are limited → can become bottleneck 👉 Threads + DB pool + latency = your real system limits 3 Real Bottlenecks in every Spring Boot app: • Thread pool (Tomcat) • Connection pool (HikariCP) • Database capacity If any one fails → your system slows or crashes. Why this matters? Understanding this helps you: ✔ Debug production issues ✔ Optimize performance ✔ Design scalable systems ✔ Crack backend interviews with confidence Final Thought: Writing APIs is easy. Understanding execution flow is what makes you a backend engineer. Highly recommended read if you're working with Spring Boot: Inside a Spring Boot Request — Threads, Security, Transactions & System Limits Explained #SpringBoot #Java #BackendDevelopment #Microservices #SystemDesign #SoftwareEngineering

@Service in Spring Boot @Service is used to define the business logic layer in a Spring Boot application. It tells Spring: “This class contains the core logic of the application.” Key idea: • Processes data • Applies business rules • Connects Controller and Repository Works closely with: • @Repository → Fetches data • @RestController → Handles requests In simple terms: @Service → Handles Logic Understanding @Service helps you keep your application clean, organized, and maintainable. #SpringBoot #Java #BackendDevelopment #LearningInPublic