Rajesh Kumar Mohan’s Post

Top 5 Spring Boot mistakes that silently kill your app in production. 🚨 Everything works fine in dev… But in production, these small mistakes turn into major outages. If you’re a Spring Boot developer, double-check these 👇 ❌ 1️⃣ ddl-auto=update in Production 👉 Hibernate auto-modifies your database schema on startup ✋ Adds columns silently ✋ Never removes them ✋ One bad entity change = production table altered No rollback. No audit trail. No control. ✅ Fix: Use ddl-auto=none or validate in production. ⏱ 2️⃣ No Read Timeout on HTTP Clients 👉 Your service calls another service… and waits forever. ✋ Threads get blocked ✋ System slows down under load ✋ Eventually leads to cascading failures ✅ Fix: Always set ALL 3 timeouts Connection Timeout: 3s Read Timeout: 5s Connection Request Timeout: 2s ⚠️ 3️⃣ @Transactional on Private Methods 👉 This is silently ignored. ✋ No transaction created ✋ No rollback happens ✋ No warning or error Same applies to: ✋ @Async ✋ @Cacheable ✋ @Retryable Because Spring AOP works via proxies. 🔥 4️⃣ Returning Entities Directly from Controller 👉 Looks easy… but dangerous. ✋ Jackson calls getters → triggers lazy loading ✋ @OneToMany → loads 1000s of records silently ✋ Circular references → StackOverflowError ✅ Fix: Always return DTOs, not entities. 💥 5️⃣ Default HikariCP Pool + Long Transactions 👉 Default pool size = 10 connections Now imagine: ✋ @Transactional holds DB connection until method ends ✋ You call an external API inside transaction (5 seconds) ✋ 10 concurrent requests → pool exhausted 👉 Request #11 waits… 👉 Times out after 30 seconds Production slowdown starts here. 🧠 What’s the Pattern? 👉 These are not syntax errors. 👉 These are design mistakes. 👉 They don’t fail immediately… 👉 They fail under real production load. ⚡ Final Thought 👉 Good developers write working code. 👉 Great engineers write code that survives production. 👉 Which of these mistakes have you seen in real projects? 👇 #SpringBoot #Java #BackendDevelopment #Microservices #SoftwareEngineering #TechInterview #ProductionIssues #InterviewPrep #Softwaredeveloper

Was working on a Spring Boot REST API the other day. Everything looked fine entity class, repository, controller all set up. But two fields, createdAt and updatedAt, were coming back null in every response. Spent time checking the constructor, the DTO mapping, the database config. Turns out I just needed two annotations: @CreationTimestamp → auto-sets the time when record is created @UpdateTimestamp → auto-updates the time on every save Two lines. That's it. Hibernate handles everything behind the scenes you don't set these manually. One more thing I'd missed without @JsonFormat, Java's Timestamp serializes weirdly in JSON. Add this and it formats cleanly: @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss") Small things. But they'll silently break your API if you miss them. #Java #SpringBoot #Backend #LearningInPublic #HibernateJPA

One thing I’ve learned building backend systems: Audit logging always starts as a “simple requirement” …and ends up being a complex subsystem. - Who changed what? - When did it happen? - Can we query it efficiently? Most teams either: 1. Over-engineer it 2. Or build something they regret later So I decided to build it properly once. Introducing nerv-audit (now on Maven Central): A Spring Boot audit framework powered by Hibernate Envers, with: - Clean architecture - Queryable audit history - Production-ready design If you're building serious systems, this is something you’ll eventually need. Full write-up here: https://lnkd.in/g2sv9dsM Curious how others are handling audit trails in their systems 👇 #SpringBoot #Java #SoftwareEngineering #Backend #OpenSource

Thread Pools to Virtual Threads. 🧵 OutOfMemoryError it is a nightmare that has always haunted Java developers. We're always been stuck with Platform Threads (heavyweight wrappers around OS threads). Since each one cost about 1MB of memory, handling 10,000 concurrent requests meant you either needed a massive, expensive server or had to write complex reactive code that nobody actually wants to debug. Enter Project Loom (Java 21+). I’ve been diving into Virtual Threads, and the "blocking" game has completely changed. Here’s why this matters for the modern backend: Cheap as Chips: Virtual threads are managed by the JVM, not the OS. They only cost a few hundred bytes. You can literally spawn one million threads on a standard laptop without breaking a sweat. The "Thread-per-Request" Revival: We can go back to writing simple, readable, synchronous code. No more "Callback Hell" or complex Mono/Flux chains just to keep the CPU busy while waiting for a database response. Massive Throughput: In I/O-heavy applications (which most Spring Boot apps are), Virtual Threads allow the CPU to switch to other tasks instantly while one thread waits for a slow API or SQL query. How to use it in Spring Boot 3.2+? It’s literally one line in your application.properties: spring.threads.virtual.enabled=true By flipping this switch, Tomcat/Undertow starts using Virtual Threads to handle web requests. It’s a complete paradigm shift that lets us build more scalable systems with less infrastructure cost. The takeaway for teams: We no longer have to choose between "easy-to-read code" and "high-performance code." With Java 21, we get both. #Java #SpringBoot #BackendDevelopment #ProjectLoom #SoftwareEngineering #Scalability #JVM

Excited to share Querier, our new open-source Java project for type-safe SQL building. If you work with Java and SQL, you know how quickly queries can become hard to read, hard to maintain, and even harder to refactor safely. Querier is designed to make that experience cleaner by helping you build SQL in a way that is more expressive, safer, and easier to evolve. Query execution agnostic, Querier can be used with most Java DB frameworks such as: Spring JDBC, Hibernate native query, jOOQ, R2DBC, Vert.x SQL... We built this project to make SQL feel more natural in Java while keeping type safety front and center. Check it out on GitHub: https://lnkd.in/duBA-X3x Project page: https://lnkd.in/dkNFKnsm #Java #OpenSource #SQL #SoftwareEngineering #BackendDevelopment #GitHub

🚨 𝗬𝗼𝘂𝗿 𝗦𝗽𝗿𝗶𝗻𝗴 𝗕𝗼𝗼𝘁 𝗔𝗽𝗽 𝗜𝘀 𝗤𝘂𝗶𝗲𝘁𝗹𝘆 𝗕𝘂𝗿𝗻𝗶𝗻𝗴 𝗤𝘂𝗲𝗿𝗶𝗲𝘀 🤯 Most developers use @𝗙𝗼𝗿𝗺𝘂𝗹𝗮 and @𝗘𝗻𝘁𝗶𝘁𝘆𝗚𝗿𝗮𝗽𝗵 interchangeably. That one mistake can turn a 1-query operation into 1,001. 𝗪𝗵𝗮𝘁'𝘀 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗵𝗮𝗽𝗽𝗲𝗻𝗶𝗻𝗴 𝘂𝗻𝗱𝗲𝗿 𝘁𝗵𝗲 𝗵𝗼𝗼𝗱? @Formula looks innocent: @𝙁𝙤𝙧𝙢𝙪𝙡𝙖("(𝙎𝙀𝙇𝙀𝘾𝙏 𝘾𝙊𝙐𝙉𝙏(*) 𝙁𝙍𝙊𝙈 𝙤𝙧𝙙𝙚𝙧𝙨 𝙤 𝙒𝙃𝙀𝙍𝙀 𝙤.𝙘𝙪𝙨𝙩𝙤𝙢𝙚𝙧_𝙞𝙙 = 𝙞𝙙)") 𝙥𝙧𝙞𝙫𝙖𝙩𝙚 𝙇𝙤𝙣𝙜 𝙤𝙧𝙙𝙚𝙧𝘾𝙤𝙪𝙣𝙩; But Hibernate fires a separate subquery for every row fetched. 500 customers → 500 extra DB hits. That's the 𝗡+𝟭 problem wearing a clean disguise. @𝗘𝗻𝘁𝗶𝘁𝘆𝗚𝗿𝗮𝗽𝗵 𝗱𝗼𝗲𝘀 𝗶𝘁 𝗿𝗶𝗴𝗵𝘁: @𝙀𝙣𝙩𝙞𝙩𝙮𝙂𝙧𝙖𝙥𝙝(𝙖𝙩𝙩𝙧𝙞𝙗𝙪𝙩𝙚𝙋𝙖𝙩𝙝𝙨 = {"𝙤𝙧𝙙𝙚𝙧𝙨", "𝙖𝙙𝙙𝙧𝙚𝙨𝙨"}) 𝙇𝙞𝙨𝙩<𝘾𝙪𝙨𝙩𝙤𝙢𝙚𝙧> 𝙛𝙞𝙣𝙙𝘼𝙡𝙡𝙒𝙞𝙩𝙝𝙊𝙧𝙙𝙚𝙧𝙨(); One JOIN. All related data. Done. The real-world gap Same 500 products, with category + supplier associations: ❌ Wrong fetch strategy → 1,001 queries ✅ @EntityGraph → 1 query Same data. P99 latency going from 80ms to 4 seconds. In production. 𝗪𝗵𝗲𝗻 𝘁𝗼 𝘂𝘀𝗲 𝘄𝗵𝗶𝗰𝗵  • ScenarioUseComputed value (count, sum) ->@Formula  • Fetching related entities -> @EntityGraph  • Sort/filter by derived column -> @Formula  • Avoiding lazy loading on APIs -> @EntityGraph One question cuts through the confusion every time: "Am I computing something, or loading something?" They're not competing tools — they solve different problems. The mistake is reaching for @𝗙𝗼𝗿𝗺𝘂𝗹𝗮 where a JOIN belongs. Most Spring Boot performance issues I've seen weren't bad logic. They were the wrong fetch strategy in the right place. Have you hit this in production? Drop it in the comments 👇 #Java #SpringBoot #Programming #SoftwareEngineering #SoftwareDevelopment #JPA #Hibernate #BackendDevelopment #BackendEngineering #APIDesign #SystemDesign #PerformanceOptimization #CleanCode #CodeQuality #TechDebt #TechCommunity #100DaysOfCode #LearnToCode #Developer #CodingLife

Day 21. My API crashed with a StackOverflowError. Not because of bad code. Because of a relationship I didn’t think twice about. I had this: @Entity public class User { @OneToMany(mappedBy = "user") private List<Order> orders; } @Entity public class Order { @ManyToOne private User user; } Looks normal. Until you return it as JSON. Here’s what actually happens: → User → Orders → User → Orders → User… → Infinite recursion → StackOverflowError → Your API crashes That’s not a bug. That’s how your model is designed. Hibernate understands it. Jackson doesn’t. So I fixed it. (see implementation below 👇) Now: → DTOs control the response → No circular references → No accidental data explosion The hard truth: → Bidirectional relationships are easy to write → They’re dangerous to expose → You won’t notice until production Returning entities is convenient. Controlling your API response is what makes you a backend developer. Have you ever hit this error? 👇 Drop it below #SpringBoot #Java #Hibernate #BackendDevelopment #JavaDeveloper

Things nobody tells you about Java Spring Boot - Until you’re in production After working on enterprise-scale applications handling 75,000+ daily transactions for a Fortune 5 client, here are my biggest takeaways: ✅ Design for failure — Always implement circuit breakers (Resilience4j). Production will surprise you. ✅ Kafka is a game changer — Async event-driven architecture saved us during peak load spikes. ✅ Database tuning matters more than code — SQL query optimization saves more performance than any code refactor. ✅ Don’t ignore logging — Structured logs with correlation IDs across microservices saved hours of debugging. ✅ Test early, test often — JUnit, Mockito and BDD approach caught bugs before they reached production. ✅ API contracts — Poor REST API design causes more problems than bad code. #Java #SpringBoot #Microservices #BackendDevelopment #SoftwareEngineering #TechCommunity #JavaDeveloper

Stop putting Lombok’s @Data on your JPA Entities. I know it saves time. You create a new Entity, slap @Data at the top of the class, and instantly get all your getters, setters, and string methods without writing boilerplate. But after 9 years of debugging Spring Boot applications, I can tell you this is one of the most common ways to silently crash your server in production. Here is why Senior Engineers ban @Data on the database layer: 1. The StackOverflowError Trap If you have a bidirectional relationship (like a User entity that has a list of Order entities, and an Order points back to a User), @Data generates a toString() method that calls the toString() of its children. User calls Order, Order calls User, and your app crashes in an infinite loop the second you try to log it. 2. The Performance Killer @Data automatically generates equals() and hashCode(). In Hibernate, evaluating these on lazy-loaded collections can accidentally trigger a massive database query just by adding the entity to a HashSet. You suddenly fetched 10,000 records without writing a single SELECT statement. The Senior Fix: Keep your database entities explicit and predictable. Instead of @Data, just use @Getter and @Setter. If you absolutely need a toString(), write it yourself or use @ToString.Exclude on your relational fields to break the loop. Lombok is an amazing tool, but using it blindly on your entities is a ticking time bomb. Have you ever taken down a dev environment because of an infinite toString() loop? Let's share some war stories below. 👇 #Java #SpringBoot #Hibernate #CleanCode #SoftwareEngineering #BackendDevelopment #LLD #SystemDesign

🧬 Spring Boot – Understanding API Responses Today I explored how Spring Boot sends data from backend to frontend. 🧠 Key Learnings: ✔️ Returning a Java object automatically converts it to JSON ✔️ Spring Boot uses Jackson internally for this conversion ✔️ "@ResponseBody" ensures data is sent directly as response 💡 Best Practice: 👉 Using "@RestController" simplifies everything (Combination of @Controller + @ResponseBody) ✔️ Explored different return types: • Object • List • String • ResponseEntity (for better control over status & response) 🔁 API Flow: Request → Controller → Service → Return Object → JSON Response → Client 💻DSA Practice: • Even/Odd check using modulus • Sum of first N numbers (optimized using formula) ✨ Understanding how backend responses work is key to building real-world REST APIs. #SpringBoot #Java #BackendDevelopment #RESTAPI #WebDevelopment #DSA #LearningInPublic #SoftwareEngineering