Backend Developer Journey Day 40: LeetCode Breakthrough and Hibernate Fix

🚨 I almost overcomplicated this problem… but pattern recognition saved me. Day 25 of my Backend Developer Journey — and today was all about thinking in cycles 🔁 🧠 LeetCode Breakthrough Solved LeetCode 3488. Closest Equal Element Queries 💡 What clicked: → Group indices using HashMap → Treat indices as circular (important!) → Compare nearest left & right occurrences ⚡ The real trick: Not linear thinking… but circular distance calculation 🔍 Key Insight Instead of checking all elements: 👉 Preprocess positions 👉 Use modulo to simulate circular array 👉 Reduce time complexity significantly 🔗 My Submission: https://lnkd.in/gKBBY7ds ☕ Spring Boot Learning 🔄 Hibernate Entity Lifecycle Today I learned how Hibernate manages objects internally: 👉 Transient – Object created, not in DB 👉 Persistent – Connected to DB (tracked by Hibernate) 👉 Detached – Exists but not tracked 👉 Removed – Marked for deletion 💡 Why this matters: Understanding lifecycle = avoiding unexpected DB behavior 🧠 The Shift 👉 Problems are not always linear 👉 Sometimes the data structure defines the solution 👉 Backend isn’t just coding — it’s understanding system behavior 📘 Spring Boot Notes: https://lnkd.in/gRgxP7Th 📈 Day 25 Progress: ✅ Stronger problem-solving ✅ Better understanding of Hibernate internals ✅ Thinking beyond brute force 💬 Have you ever solved a problem only after changing the way you looked at it? #100DaysOfCode #BackendDevelopment #SpringBoot #Java #LeetCode #CodingJourney

🚨 I solved this problem… but the real learning was in how I stored data. Day 26 of my Backend Developer Journey — and today was all about thinking ahead while iterating 👇 🧠 LeetCode Breakthrough Solved LeetCode 3761. Minimum Absolute Distance Between Mirror Pairs 💡 What clicked: → Reverse the number to find its mirror → Store reversed values in HashMap → Check distance while iterating ⚡ The key trick: Instead of searching later… 👉 Prepare data in advance while traversing 🔍 Key Insight 👉 Store future-use data (reversed numbers) 👉 Avoid nested loops 👉 Reduce time complexity to O(n) 🔗 My Submission: https://lnkd.in/gUZ5QUKc ☕ Spring Boot Learning 🔄 Hibernate Entity Lifecycle Deep Dive Today I didn’t just learn states… I understood how Hibernate actually behaves internally 👉 Transient – Only in heap memory 👉 Persistent – Connected & tracked by Hibernate 👉 Detached – Exists but not tracked 👉 Removed – Marked for deletion ⚡ Real Game Changer 💡 Persistence Context (First-Level Cache) 👉 Same entity = same reference 👉 Avoids repeated DB calls 👉 Managed automatically using @Transactional 🔥 Powerful Concept 👉 Updating entity WITHOUT calling save() still works Why? Because Hibernate tracks changes in Persistent State ⚡ This is called: Dirty Checking (not Dirty Read — common mistake 👀) 🧠 The Shift 👉 Efficient coding = smart data preparation 👉 Hibernate is not magic — it’s predictable when understood 👉 Backend = Data + Lifecycle + Optimization 📘 Spring Boot Notes: https://lnkd.in/gRgxP7Th 📈 Day 26 Progress: ✅ Improved hashmap intuition ✅ Understood Hibernate internals deeply ✅ Learned real-world DB optimization concept 💬 Did you know Hibernate updates data even without calling save()? 😄 #100DaysOfCode #BackendDevelopment #SpringBoot #Java #LeetCode #CodingJourney

🚀 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗮𝗻 𝗢𝗿𝗱𝗲𝗿 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 𝗦𝘆𝘀𝘁𝗲𝗺 𝗳𝗿𝗼𝗺 𝗦𝗰𝗿𝗮𝘁𝗰𝗵 — 𝗣𝗮𝗿𝘁 𝟭 Started working on a production-style Order Management System. Not a CRUD app — but a backend that handles concurrency, data consistency, and service decoupling the way real systems do. Core design choice: 𝗘𝘃𝗲𝗻𝘁-𝗗𝗿𝗶𝘃𝗲𝗻 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 Services don’t call each other directly. OrderService publishes an OrderCreatedEvent, and InventoryListener plus AuditListener react independently using Spring Application Events. This means no tight coupling. Adding a new listener requires zero changes to existing code. And if we switch to Kafka later, listeners remain completely untouched. 𝗪𝗵𝗮𝘁 𝗣𝗵𝗮𝘀𝗲 𝟭 𝗰𝗼𝘃𝗲𝗿𝘀 ✍️ 𝗣𝗲𝘀𝘀𝗶𝗺𝗶𝘀𝘁𝗶𝗰 𝗟𝗼𝗰𝗸𝗶𝗻𝗴 — Using @Lock(PESSIMISTIC_WRITE) on inventory queries. Two users, last item — one wins cleanly. No overselling. 𝗜𝗱𝗲𝗺𝗽𝗼𝘁𝗲𝗻𝗰𝘆 — Unique key per order ensures duplicate requests return the existing order, not a new one. 𝗜𝗺𝗺𝘂𝘁𝗮𝗯𝗹𝗲 𝗗𝗧𝗢𝘀 — Java Records with Bean Validation at the controller boundary. 𝗚𝗹𝗼𝗯𝗮𝗹 𝗘𝘅𝗰𝗲𝗽𝘁𝗶𝗼𝗻 𝗛𝗮𝗻𝗱𝗹𝗶𝗻𝗴 — Structured JSON errors, correct HTTP status codes, and no stack trace leaks. 𝗔𝘂𝗱𝗶𝘁 𝗧𝗿𝗮𝗶𝗹 — Every state transition is logged to order_events with timestamps. 𝗣𝗢𝗦𝗧 /𝗮𝗽𝗶/𝗼𝗿𝗱𝗲𝗿𝘀 → 𝗢𝗿𝗱𝗲𝗿𝗦𝗲𝗿𝘃𝗶𝗰𝗲 (𝘀𝘁𝗮𝘁𝘂𝘀: 𝗖𝗥𝗘𝗔𝗧𝗘𝗗) → 𝗽𝘂𝗯𝗹𝗶𝘀𝗵𝗲𝘀 𝗢𝗿𝗱𝗲𝗿𝗖𝗿𝗲𝗮𝘁𝗲𝗱𝗘𝘃𝗲𝗻𝘁 → 𝗜𝗻𝘃𝗲𝗻𝘁𝗼𝗿𝘆𝗟𝗶𝘀𝘁𝗲𝗻𝗲𝗿 (𝗿𝗲𝘀𝗲𝗿𝘃𝗲𝘀 𝘀𝘁𝗼𝗰𝗸 𝘄𝗶𝘁𝗵 𝗽𝗲𝘀𝘀𝗶𝗺𝗶𝘀𝘁𝗶𝗰 𝗹𝗼𝗰𝗸) → 𝗔𝘂𝗱𝗶𝘁𝗟𝗶𝘀𝘁𝗲𝗻𝗲𝗿 (𝗹𝗼𝗴𝘀 𝘁𝗼 𝗼𝗿𝗱𝗲𝗿_𝗲𝘃𝗲𝗻𝘁𝘀) 𝗧𝗲𝗰𝗵 𝗦𝘁𝗮𝗰𝗸 Spring Boot 4 · Java 17 · Spring Data JPA · H2 · Hibernate 𝗡𝗲𝘅𝘁 Building a payment system using the Strategy Pattern with multiple methods and no if-else chains. But the real question is: what happens when payment fails after inventory is already deducted? Compensating transactions. Part 2 soon ✨ #Java #SpringBoot #SystemDesign #BackendEngineering #SoftwareArchitecture #BuildInPublic

#Post4 In the previous post, we understood how request mapping works using @GetMapping and others. Now the next question is 👇 How does Spring Boot handle data sent from the client? That’s where @RequestBody comes in 🔥 When a client sends JSON data → it needs to be converted into a Java object. Example request (JSON): { "name": "User", "age": 25 } Controller: @PostMapping("/user") public User addUser(@RequestBody User user) { return user; } 👉 Spring automatically converts JSON → Java object This is done using a library called Jackson (internally) 💡 Why is this useful? • No manual parsing needed • Clean and readable code Key takeaway: @RequestBody makes it easy to handle request data in APIs 🚀 In the next post, we will understand @PathVariable and @RequestParam 🔥 #Java #SpringBoot #BackendDevelopment #RESTAPI #LearnInPublic

🚀 Learning Content Negotiation in Spring Boot & How Jackson Works Behind the Scenes Recently, I explored one of the most interesting concepts in Spring Boot — Content Negotiation and how data conversion happens using Jackson. Here’s what I learned 👇 🔹 What is Content Negotiation? Content Negotiation is a mechanism where the server decides which format (JSON, XML, etc.) to return based on the client request. 👉 Client sends request with Accept header 👉 Server responds with appropriate format Example: - Accept: application/json → JSON response - Accept: application/xml → XML response --- 🔹 How Spring Boot Handles It? Spring Boot uses: ✔️ HttpMessageConverters ✔️ ContentNegotiationManager These components automatically decide how to convert Java objects into the requested format. --- 🔹 Role of Jackson in Conversion Jackson is the default library used by Spring Boot for JSON processing. 👉 It converts: Java Object ⇄ JSON Behind the scenes: ✔️ Uses ObjectMapper ✔️ Serializes Java objects → JSON ✔️ Deserializes JSON → Java objects --- 🔹 Example Flow 1️⃣ Client sends request (Accept: application/json) 2️⃣ Controller returns Java object 3️⃣ Jackson converts it into JSON 4️⃣ Response sent to client --- 🔹 Why It’s Important? ✅ Makes APIs flexible ✅ Supports multiple data formats ✅ Reduces manual conversion work ✅ Improves API design --- 💡 Understanding this helped me realize how Spring Boot internally manages API responses so efficiently! #SpringBoot #Java #BackendDevelopment #RESTAPI #Jackson #LearningJourney

🚀 Top 20 Most Useful Spring Boot Annotations Every Developer Should Know Spring Boot is not about memorizing annotations. It is about knowing which one to reach for and why. Here are the 20 that actually matter in real projects: → @SpringBootApplication – This annotation is used to bootstrap a Spring Boot application and launch it through the Java main method. → @RestController – Build REST APIs easily → @RequestMapping – Define base URL paths → @GetMapping / @PostMapping – Handle HTTP requests → @RequestBody – Convert JSON request into a Java object. → @Valid – Data Validation Made Easy → @PathVariable– It helps you extract values directly from the URL. → @RequestParam– is used to get values from URL query parameters. → @Service – Business logic layer → @Repository – Database interaction layer → @Entity – Map Java class to database table → @Id – Define primary key → @Table – is used to map a Java entity class to a specific database table name. → @Autowired – Dependency injection (use constructor injection in modern practice) → @Transactional – is used to manage database transactions automatically. → @Component  –   is the fallback for everything else → @Configuration  –   is used to define custom Spring configuration classes. → @Bean – registers objects you cannot annotate directly → @ControllerAdvice –  centralizes exception handling → @EnableScheduling –  is used to enable scheduled tasks in your Spring Boot application. Knowing these 20 is the difference between writing Spring Boot code and actually understanding the framework. #SpringBoot #Java #BackendDevelopment #DevOps #SoftwareEngineering #Microservices #LearningJourney

Thought I understood lazy loading. Hibernate humbled me 😄 ⸻ Had an entity: Device with a lazily loaded: configurations ⸻ Flow looked simple: • Fetch device • Pass it into an async CompletableFuture • Access device.getConfigurations() ⸻ And then: 💥 LazyInitializationException ⸻ Why? Because lazy loading needs an active Hibernate session. By the time async code executed: 👉 Original transaction/session was gone So Hibernate had no way to fetch the lazy association. ⸻ What looked harmless: device.getConfigurations() actually depended on context. ⸻ Fix options: ✔ Load required data before async boundary ✔ Convert entity → DTO before passing async ✔ Explicitly fetch associations if needed ⸻ Takeaway: ORM entities are not just data. They often carry assumptions about 👉 transaction boundaries 👉 session lifecycle 👉 thread context ⸻ Async + Lazy Loading = check twice 😄 #java #SoftwareEngineering #LearnInPublic

🚀 JPA Relationships Deep Dive with Ownership Explained JPA relationships look simple on the surface — but the real challenge starts when you deal with ownership, foreign keys, and bidirectional mapping. Instead of just theory, this infographic focuses on what actually matters when you're working with Spring Boot + Hibernate in real projects: 🔹 Clear breakdown of One-to-One, One-to-Many, and Many-to-Many 🔹 Who is the Owning Side ✅ and who is the Inverse Side 🔁 🔹 Why ManyToOne is ALWAYS the owning side (and why it matters) 🔹 How foreign keys are mapped and controlled in the database 🔹 Visual explanation of FK placement (child table vs join table) 🔹 Common mistake: updating only one side of the relationship ❌ 🔹 Correct approach: keeping both sides in sync ✔️ 🔹 Quick notes on FetchType and Cascade for better performance 💡 This is not just for interviews — it’s for writing bug-free, production-ready JPA code. 🔥 Key Takeaways 👉 Owning side = controls the relationship in DB 👉 mappedBy = inverse side (read-only for updates) 👉 FK always belongs to the owning side 👉 Always update BOTH sides in bidirectional relationships If you're building APIs with Spring Boot or working on backend systems, mastering this will save you from subtle and frustrating bugs. #Java #SpringBoot #Hibernate #JPA #BackendDevelopment #FullStackDeveloper #SoftwareEngineering #Programming #Coding #Developers #Tech #CleanCode #SystemDesign #JavaDeveloper #WebDevelopment #CodingTips #DeveloperCommunity #LearnInPublic

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

🚀 Still writing complex JOIN queries to manage relationships? What if you could handle everything using simple Java objects… without worrying about SQL complexity? That’s exactly where Association Mapping in Spring Boot (JPA) becomes a game-changer 🔥 🔍 What this image explains Managing relationships between database tables is one of the most challenging parts of backend development. 👉 Association Mapping solves this by: ✔ Defining how entities are connected ✔ Mapping real-world relationships directly in your code ✔ Letting JPA handle the underlying SQL 📌 Types of Relationships 🔹 One-to-One → One entity is linked to exactly one other entity 🔹 One-to-Many → One parent can have multiple children 🔹 Many-to-One → Multiple entities can relate to one parent 🔹 Many-to-Many → Complex relationships using a join/lookup table 💡 Why It Matters ✔ Cleaner & more readable code ✔ Maintains strong data integrity ✔ Reduces the need for complex SQL queries ✔ Improves scalability and maintainability 🔥 Core Insight: Stop thinking in tables… Start thinking in objects and relationships — JPA will handle the rest. 💬 Quick Question: Which mapping do you use most in real projects — One-to-Many or Many-to-One? #SpringBoot #Java #JPA #Hibernate #BackendDevelopment #SoftwareEngineering #DatabaseDesign #LearningInPublic #Developers #TechContent