Pattern Recognition Saves the Day with LeetCode 3488 Solution

🚨 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

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

🚀 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗮𝗻 𝗢𝗿𝗱𝗲𝗿 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 𝗦𝘆𝘀𝘁𝗲𝗺 𝗳𝗿𝗼𝗺 𝗦𝗰𝗿𝗮𝘁𝗰𝗵 — 𝗣𝗮𝗿𝘁 𝟭 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

Day 29. I enabled query logging for the first time. What I saw surprised me. I had this: List<User> users = userRepository.findAll(); Simple. Clean. One line. I assumed Hibernate was handling it efficiently. Then I added this: spring.jpa.show-sql=true And watched the logs. Not one query. Multiple hidden ones. → Fetch users → Then fetch relationships → Then more queries behind the scenes Hibernate wasn’t optimizing anything. It was executing exactly what I told it to — lazily, one relationship at a time. That’s when it clicked. ORM doesn’t optimize your queries. It executes what you tell it to. (see fix below 👇) Or better: 👉 Fetch only what you need (DTO projection) What I learned: → Hibernate is not magic → Default behavior is not always efficient → You are responsible for query performance The hard truth: → “It works” doesn’t mean “it’s optimized” → ORM hides complexity — it doesn’t remove it Writing code that runs is easy. Understanding what your database is actually doing is what makes you a backend developer. Have you ever checked your query logs and been surprised? 👇 Drop your experience #SpringBoot #Java #Hibernate #BackendDevelopment #Performance #JavaDeveloper

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

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

#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

Fresh off the repo! 🔝 We've released json2jsontransformer — a config-driven Java library that transforms JSON structures using JSONPath expressions. No code changes needed for new field mappings. Key highlights: → JSON config files define all mappings → JSONPath-based extraction with fallback paths → Pluggable custom transformation logic → Thread-safe, lightweight, Java 11+ → Available on Maven Central today Whether you're normalizing webhook payloads, mapping API responses, or reshaping data between systems, this library keeps your transformation logic out of your codebase and in simple, readable config. Explore the project → https://lnkd.in/g5vBt8Jb Feedback and contributions welcome! Special thanks: Pratik Lala, Pooja Chowdhary, Suthirr Preethum Balasubramanian, Chinmay Bhatt, Muzaffar Malik, Arun Kupireddy, Daniel L. Moise, Ashish Pandey, Venkat Vedam, Bharat Bhatia, Ruppi Rana

🚀 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

🚀 Day 7/45 – Backend Engineering (JPA & Hibernate) Most performance issues in backend apps don’t come from logic — they come from how data is fetched from the database. Today I focused on one of the most common JPA pitfalls: ❗ The N+1 Query Problem 💡 What happens: You fetch a list of entities (1 query) For each entity, JPA triggers another query for related data Result → 1 + N queries 👉 This can silently kill performance in production. 🔍 Example: Fetching a list of users and their orders: 1 query for users N queries for orders ❌ 🔧 Fix: Use JOIN FETCH Use Entity Graphs Choose fetch type wisely (LAZY vs EAGER) 🛠 Practical: Tested API behavior with lazy loading and saw how queries multiplied without optimization. 📌 Real-world impact: Ignoring this leads to: Slow APIs High DB load Poor scalability 🔥 Takeaway: ORMs don’t guarantee performance. You must understand what queries are actually being executed. Currently building a production-ready backend system — sharing real backend lessons daily. https://lnkd.in/gJqEuQQs #Java #SpringBoot #Hibernate #BackendDevelopment #Performance #LearningInPublic