Spring Bean Lifecycle: Creation to Destruction Explained

🚀 I just spent 2 hours debugging a production issue... The problem? I was using the wrong Spring Bean Scope! 😅 After learning about this topic, I realized many developers make the same mistake. So I created this simple visual guide to help everyone understand when to use which scope. Here's what each scope means in SIMPLE terms: 🔴 Singleton = One Principal for the whole school 🔵 Prototype = Each student gets their own notebook 🟡 Request = New movie ticket for each show 🟣 Session = Your shopping cart until you logout 🟠 Application = School library shared by everyone 💡 Golden Rule: When in doubt, use Singleton (it's the default!) The most common mistakes I see: ❌ Using Singleton for user-specific data (everyone sees the same data!) ❌ Using Prototype everywhere (kills performance) ❌ Not understanding the difference between Session and Request 📊 Swipe through to see: ✅ When to use each scope ✅ Real-world examples ✅ Common pitfalls to avoid ✅ Quick decision guide Found this helpful? Save it for later and share with your team! 🔖 What's your biggest challenge with Spring Bean Scopes? Drop a comment below! 👇 --- 🎥 Credits: Learned from Shrayansh Jain excellent tutorial #SpringBoot #Java #Backend #SpringFramework #SoftwareEngineering #Developer #Coding #TechTips #Programming #BackendDevelopment

Why I Choose @Qualifier over @Primary As I’ve been diving deeper into Spring Dependency Injection, I’ve been weighing the pros and cons of how we handle multiple bean implementations. While Spring gives us multiple tools, they aren't created equal. @Primary vs. @Qualifier 1. The @Primary Approach I initially looked at @Primary because it’s convenient. It allows the implementation class to decide the "default" bean. The Risk: In a large project, having multiple classes marked as @Primary for the same interface leads to a startup crash. It’s "implicit", the controller just hopes it gets the right one. 2. The @Qualifier Approach (My Choice) I’ve decided to stick with @Qualifier. Why? Precision. By using @Qualifier("mySpecificBean") in the constructor, I am being explicit about exactly which "worker" the controller needs. It removes the guesswork. Even if a new developer adds 10 more implementations, my controller remains "locked" to the correct logic. My Takeaway In software engineering, Explicit is almost always better than Implicit. @Primary is great for a quick default, but @Qualifier gives you the control and readability that a robust application needs. #Java #SpringBoot #BackendDevelopment #SoftwareEngineering #CodingJourney #DependencyInjection

🟢 6 Clean Code Tips That Will Change How You Write Code Clean code is not about being clever. It's about being clear — for the next developer who reads it. (Spoiler: it's usually you.) Here's what I apply every single day 01 — Meaningful Names Name your intent, not your type. int d; ❌ → int daysUntilDeadline; ✅ 02 — Functions Do One Thing Only If your method name contains the word "and" — it's doing too much. Split it. 03 — Avoid Magic Numbers if (status == 3) ❌ → if (status == OrderStatus.Shipped) ✅ Give numbers a name that explains what they mean. 04 — Comments Explain Why, Not What Good code explains itself. Comments should explain the reasoning — not describe what the code obviously does. 05 — Keep Functions Short If your function doesn't fit on one screen — it's too long. Refactor until it does. 06 — DRY — Don't Repeat Yourself Every piece of logic should live in exactly one place. Duplication = double the bugs. 💡 Clean code isn't written. It's rewritten. Which of these do you struggle with the most? #CleanCode #SoftwareEngineering #BackendDevelopment #CSharp #DotNet #Programming #CodeQuality #DRY

How Spring Uses Topological Sort (Simple Explanation) When working with the Spring Framework, everything feels smooth — you define your components, and Spring handles the rest. But behind the scenes, Spring is solving an important problem: 👉 In what order should objects (beans) be created when they depend on each other? 🧩 The Problem In any real application, different parts depend on each other. For example: A service depends on a repository A repository depends on a database So, you cannot create everything randomly. 👉 You must follow the correct order. ⚡ What Spring Does Spring looks at all these dependencies and builds a relationship like this: Database → Repository → Service Then it ensures: 👉 First create Database, then Repository, then Service 🧠 Where Topological Sort Comes In This is exactly what topological sort does: 👉 It finds a valid order of tasks where dependencies are respected. Spring internally uses this idea to: Understand which bean depends on which Arrange them in the correct sequence Create them without errors 🔄 Inside Spring The Spring IoC Container works like a smart manager: It scans all components Understands their dependencies Decides the correct creation order Initializes everything step by step 🚨 Circular Dependency Problem Sometimes, a bad design creates a loop: A depends on B B depends on A In this case, no correct order exists. Spring detects this and throws an error because: 👉 Topological sorting only works when there is no cycle 💡 Why This Matters Because of this logic, Spring gives you: Proper initialization of objects No missing dependencies Clean and scalable architecture Without it, managing large applications would become very complex. 🚀 Final Thought Topological sort is not something you see directly in Spring, but it is quietly working in the background. 👉 Whenever Spring decides “what to create first and what next” 👉 It is using the logic of topological sorting. #TopologicalSort #DataStructures #Algorithms #GraphTheory #ComputerScience #SpringFramework #JavaDeveloper #BackendDevelopment #SpringBoot #SoftwareEngineering #TechLearning #CodingJourney #Developers #ProgrammingLife #LearnInPublic #TechExplained #SystemDesign #CodingConcepts

⚙️ Ever wondered how Spring manages objects behind the scenes? That’s where the Spring Bean Lifecycle comes in. Every bean in Spring goes through a series of stages from creation to destruction inside the IoC Container. Here’s the simplified lifecycle 👇 1️⃣ Instantiation Spring creates the bean object using the constructor. 2️⃣ Dependency Injection Required dependencies are injected using annotations like "@Autowired". 3️⃣ Initialization Spring calls initialization methods such as: • "@PostConstruct" • "InitializingBean" • custom "init-method" 4️⃣ Bean Ready for Use The bean is now fully initialized and can be used by the application. 5️⃣ Destruction When the application shuts down, cleanup methods are executed: • "@PreDestroy" • "DisposableBean" • custom "destroy-method" 💡 Understanding the bean lifecycle helps developers manage resources, initialize logic properly, and build better Spring applications. If you're learning Spring Boot, this is one of the core concepts you should know. #Java #SpringBoot #SpringFramework #BackendDevelopment #SoftwareEngineering #JavaDeveloper #Programming

❓ Why does Spring recommend Constructor Injection even though Field Injection works? Many developers start with Field Injection because it’s simple. But the Spring team officially recommends Constructor Injection for better design and maintainability. Here’s why 👇 1️⃣ Ensures Required Dependencies With constructor injection, dependencies must be provided when the object is created. public class OrderService { private final PaymentService paymentService; public OrderService(PaymentService paymentService) { this.paymentService = paymentService; } } If the dependency is missing, the application fails at startup — which is good because problems are detected early. With field injection, the object can be created without the dependency, which may cause runtime issues. 2️⃣ Supports Immutability Constructor injection allows fields to be final. private final PaymentService paymentService; Benefits: ✔ Object state cannot change after creation ✔ Safer and easier to maintain ✔ Better for multithreading Field injection cannot use final fields. 3️⃣ Improves Unit Testing Constructor injection makes testing simple and clean. PaymentService mockPayment = new MockPaymentService(); OrderService service = new OrderService(mockPayment); No need to start the Spring container. With field injection, you often need reflection or Spring context, which makes tests heavier. 4️⃣ Avoids Hidden Dependencies Field injection hides dependencies inside the class. @Autowired private PaymentService paymentService; With constructor injection, dependencies are explicit. public OrderService(PaymentService paymentService) Anyone reading the code immediately knows what the class depends on. 5️⃣ Detects Circular Dependencies Early Example: A → depends on B B → depends on A With constructor injection, Spring fails at startup, making the problem obvious. Field injection may hide this issue until runtime. ✅ Conclusion: Constructor Injection leads to cleaner design, better testability, and more maintainable code. #SpringBoot #Java #BackendDevelopment #SoftwareArchitecture #Programming #JavaDevelopers

One Small Mistake That Took Down a Backend Service I remember this very clearly. Everything looked fine. We deployed it. And for some time… everything worked. Then slowly things started breaking. • Response time increased • Requests started piling up • Threads got blocked Within minutes, the system became almost unresponsive. No crash. No exception. Just a system… silently slowing down. After digging deeper, we found the issue. There was no timeout configured on an external API call. When that dependency became slow, our service didn’t fail. It just kept waiting. And that waiting… took everything down. That day I learned something I still remember: In backend systems, waiting is more dangerous than failing. Fail fast → system survives Wait indefinitely → system collapses Since then, I don’t just think about the happy path. I think about: • What happens when dependency is slow • How retries behave • How failures propagate Because in real systems, failure is not the exception. It’s expected. What’s one production issue that taught you a hard lesson? #BackendEngineering #SystemDesign #Microservices #SoftwareEngineering #Java #SpringBoot #DistributedSystems #TechCareers #DeveloperLife #Programming

🚀 Day 9/100: Spring Boot From Zero to Production Topic: Dependency Injection (DI) If someone asked me to name the three most important things in Spring Boot, Dependency Injection (DI) would definitely be at the top of that list! 🏆 It might sound like a complex technical term, but the concept is actually quite simple once you break it down. The "Old School" Way ❌ Before Spring, if we wanted to use a service inside a controller, we had to manually create the object ourselves: UserService userService = new UserService(); This makes your code "tightly coupled", meaning your controller is now responsible for creating and managing that service. If the service changes, you have to go back and fix it everywhere. The Spring Boot Way (DI) ✅ With Spring, you don't use the new keyword anymore. Instead, you let the IoC Container (like the ApplicationContext) do the heavy lifting. Think of this container as a giant box that holds all your Beans (object instances). When your controller needs that service, you just ask Spring to "inject" it: @Autowired UserService userService; Why is this a game-changer? 🚀 Inversion of Control (IoC): Spring takes over the responsibility of creating and managing the object lifecycle. Cleaner Code: You don't have to write boilerplate code to instantiate objects. Decoupling: Your components don't need to know how to create their dependencies, they just know they'll be there when needed. Reduced Code Size: It keeps your project much more organized and scalable. Basically, Spring is the ultimate manager, it creates the instances, keeps them in the container, and hands them to you exactly where they are needed! See you in next post with more interesting topics. #Java #SpringBoot #SoftwareDevelopment #100DaysOfCode #Backend

I've used Cursor for a while. Then I signed up for Claude Code. I did not expect it to be this different. The context understanding is on another level. I can drop in a PDF, a spec, a full project structure and Claude actually uses it. Not just reads it. Uses it. Here's what surprised me the most: The terminal and shell management. Claude Code doesn't just write code. It operates the environment. Runs commands, reads the output, adapts. It feels less like an autocomplete and more like a junior dev who knows what they're doing. One honest caveat: token usage feels a bit heavier compared to Cursor. Could be my impression, I need more time to be sure. But it's something I'm watching. Cursor has more model options, which matters. But inside an actual project, building, debugging, iterating, I haven't felt the capability gap I expected. Still testing. But the honest take after the first weeks: Claude has earned its place in my workflow. #softwaredevelopment #claudecode #developertools