DEV Community: Rohan Mhadgut

Why IoC and DI feel the same, but are actually not

Rohan Mhadgut — Tue, 30 Sep 2025 13:37:21 +0000

Introduction:

When I first started learning Spring, I came across the concepts of Inversion of Control (IoC) and Dependency Injection (DI). The instructor explained the definitions, but to me, they sounded almost identical. If they really meant the same thing, why were there two different names? That question stuck with me. I started digging, browsing blogs, Stack Overflow, and Reddit, but I kept seeing answers that mixed up the two concepts and often called DI IoC. Like in this StackOverflow question, you could find many answers that mix up IoC with DI. After a bit more research and watching some really insightful YouTube explanations, I finally found clear, concrete definitions and the fundamental differences between IoC and DI. In this blog, I will share what I learned.

Life With Too Many Responsibilities:

To understand why Inversion of Control is useful, let’s look at some real-world examples.

Imagine a freelance website designer working alone. They have to find clients, manage billing, schedule meetings, design websites, handle updates, and deal with support requests. While it is possible to do everything, it quickly becomes exhausting and inefficient. There is little room to focus on the creative work, and every small task adds friction.

Consider one more example. Think about a busy restaurant kitchen. Without help, the head chef would have to take orders, cook every dish, clean up, restock ingredients, and even deliver food to tables. It is possible, but the chef would quickly be overwhelmed, and the quality of the food and service would suffer.

In both cases, the problem is the same: doing everything yourself leaves you overwhelmed and slows down progress

But what if we could delegate these responsibilities to someone else? What if we could find someone who could do all the dirty work for us? What if we could just invert the control?

What is IoC ?

Well, it is in the name itself: IoC stands for Inversion of Control. (I know, you probably already know that, and you are not here just for the full form.)

Let’s make it simpler.

IoC is like saying: “I don’t want to do this task anymore. From now on, it’s your responsibility.”

To visualize it, imagine a basketball team. The star player focuses on scoring points, but there is a teammate who dives for rebounds, hustles for every loose ball, defends aggressively, and takes the hits that nobody sees, someone like a Dennis Rodman or Draymond Green type of player. The star player does not have to worry about all of this because someone else is handling the gritty work. That teammate is like IoC in programming, taking care of the behind-the-scenes tasks so the main logic can shine.

Or think of a busy restaurant kitchen. The head chef focuses on creating amazing dishes while assistants prep ingredients, manage orders, and serve food. The chef still decides what should be cooked, but they do not have to manage every single detail. IoC works the same way, delegating the repetitive or logistical tasks to someone else, allowing the important work to get done efficiently.

A more technical way of explaining IoC would be: "Developers should keep their business logic clean by externalizing complicated and complex configuration, lifecycle management, and system interactions. Complex tasks should be handled by an IOC framework." (I got this definition from this YouTube video. Do check it out to get a better understanding of both the terms of IoC and DI)

IoC appears in many software scenarios. For example:

Spring Framework automatically manages object creation and wiring for you.
React handles rendering flows and updates your UI based on state changes.
Event loops and callbacks in Node.js or GUI applications invert control, letting your code react to events rather than control the execution sequence directly.

Instead of your code dictating every step, the framework or system takes over the flow. You provide the instructions, what should happen, and the framework decides when and how it will happen.

This is what makes life easier for developers. Just like the solo freelance designer or the overwhelmed chef, without IoC, you would be managing everything yourself. With IoC, you can hand off the repetitive, messy tasks and focus on what really matters.

One of the most common ways this is done in software is through Dependency Injection, which we will explore next.

You must have never thought, but even this is IoC:

Before moving to the part of DI, I would like to share an interesting example of IoC that even I didn't think of, and maybe most of you as well.

In your universities, colleges, or programming bootcamps, you must have learn a programming language like Java, Python, or JavaScript. In these programming tutorials, you must have designed some user input-based programs running on terminals that look something like this:

Please enter your name
accept the name
Please enter your password
accept the password
check user exists
Log in the user
etc....

Now, in the above scenario, you are controlling the flow of the program and not the user. As you decide what the next step the user would be doing.

Now, when you add a GUI for the same example above it would look like:

When the user types in the username field, store it in USERNAME
When the user types in the password field, store it in PASSWORD
When the user clicks on the login button, call the database to check if the user exists

So now control is inverted... instead of the computer accepting user input in a fixed order, the user controls the order in which the data is entered, and when the data is saved in the database.

You can find the reference for the above example over here.

What is DI?

Dependency Injection, or DI, is one of the most common ways that Inversion of Control is applied in software. If IoC is about handing off control of tasks, DI is about handing you exactly what you need to do your job.

Imagine basketball again. The star player needs the ball to score. Instead of running across the court to fetch it every time, a teammate passes it directly to them at the perfect moment. That is DI. The ball is a dependency, and it is being injected at the right time so the star can focus on scoring.

In real life, think of a freelance website designer. Instead of spending hours finding clients, sending invoices, and setting up meetings, they have an assistant who handles these tasks. The designer still does the creative work of building websites, but the assistant provides the resources and support exactly when needed. That is Dependency Injection at work.

In software, DI allows your objects or components to receive the dependencies they need from an external source rather than creating them themselves. This makes your code cleaner, easier to maintain, and much simpler to test. You focus on your core work while the framework or system provides all the supporting pieces.

Examples of IoC and DI using Spring:

Example of Freelancer doing everything without IoC and DI:

class Freelancer {
    private Billing billing = new Billing();
    private ClientFinder clientFinder = new ClientFinder();
    private MeetingScheduler meetingScheduler = new MeetingScheduler();

    void work() {
        clientFinder.findClients();
        meetingScheduler.schedule();
        billing.sendInvoice();
        System.out.println("Designing website...");
    }
}

Here, the Freelancer class creates and manages everything. Just like the freelance designer in our earlier example, this class is overwhelmed because it has to handle all the responsibilities itself.

Example of Freelancer with IoC and DI:

// IoC Example: By adding @Component, we tell Spring to manage the object lifecycle for us. 
// Spring will create, configure, and destroy these objects when needed.
@Component
class Billing {
    void sendInvoice() {
        System.out.println("Invoice sent");
    }
}

@Component
class ClientFinder {
    void findClients() {
        System.out.println("Clients found");
    }
}

@Component
class MeetingScheduler {
    void schedule() {
        System.out.println("Meeting scheduled");
    }
}

@Component
class Freelancer {
    private final Billing billing;
    private final ClientFinder clientFinder;
    private final MeetingScheduler meetingScheduler;

    // DI Example: By adding @Autowired, we ask Spring to provide the required dependencies. 
    // Spring injects Billing, ClientFinder, and MeetingScheduler into Freelancer automatically.
    @Autowired
    Freelancer(Billing billing, ClientFinder clientFinder, MeetingScheduler meetingScheduler) {
        this.billing = billing;
        this.clientFinder = clientFinder;
        this.meetingScheduler = meetingScheduler;
    }

    void work() {
        clientFinder.findClients();
        meetingScheduler.schedule();
        billing.sendInvoice();
        System.out.println("Designing website...");
    }
}

Now the Freelancer no longer creates Billing, ClientFinder, or MeetingScheduler. Instead, Spring handles all of that (IoC), and just passes them in (DI). The Freelancer can now focus on the actual creative work.

Summarizing the difference:

It is easy to confuse Inversion of Control and Dependency Injection because they are closely related. Both involve someone else taking care of work you would normally do, but they are not the same.

In short, all DI is IoC, because the control of providing dependencies is inverted. But not all IoC is DI, because IoC can also refer to things like event loops, callbacks, or framework-managed flows where no dependencies are being injected.

Conclusion / Takeaway:

Understanding Inversion of Control and Dependency Injection is more than just a technical detail. These concepts change the way you think about building software. By letting frameworks handle the repetitive, logistical, or timing-sensitive tasks, you can focus on solving real problems instead of wrestling with object creation, wiring, or flow management.

IoC and DI also make your code more flexible and easier to maintain. You can swap implementations, add new features, or test components in isolation without breaking the rest of your system. This is why modern frameworks rely heavily on these principles. They are not just conveniences, they are tools for writing scalable, robust, and clean software.

In short, mastering IoC and DI is like learning to delegate effectively in real life. Once you embrace this mindset, both coding and designing systems become less about doing everything yourself and more about orchestrating the right pieces to work together efficiently.

My understanding of microservices was totally wrong

Rohan Mhadgut — Mon, 29 Sep 2025 06:15:16 +0000

Introduction

I have been building CRUD applications for a long time, during my previous job, internships, and university assignments.

In a typical CRUD application, your project is divided into three major components.

Front-end: Built using HTML, CSS, JavaScript, and frameworks or libraries like React, Angular, or Vue.
Back-end: APIs built using Java with Spring Boot, Python with Django or Flask, or Node.js and Express.
Database: Where all data is stored and retrieved, using SQL databases such as MySQL or PostgreSQL, or NoSQL options like MongoDB.

This structure is often called a 3-Tier Architecture because the application is basically divided into three layers: frontend, backend, and database.

My Assumption About Microservices

Eventually, I learned about Microservices architecture, or at least I thought I did. To me, a microservice was simply a service running independently and communicating with others using REST APIs. This assumption led me to believe that if I ran my frontend, backend, and database inside Docker containers and made them communicate via REST, I was actually building a microservices-based application.

I even built such an application using Java Spring Boot, React, and MySQL, which you can check out at : Building a Full-stack ERP

Monolithic Architecture

While studying Microservices architecture again, I realized I was completely wrong. What I had built was still based on a Monolithic Architecture and not microservices.

In a Monolithic Architecture, the frontend, backend, and database all live in a single codebase and are tightly coupled. This makes it easy to get started, but as the application grows, it becomes difficult to scale, maintain, and deploy safely.

In this type of application, different teams, such as the Accounts Dev Team, Loans Dev Team, Cards Dev Team, and the UI/UX Dev Team, push their updates to the same codebase. The code is then built using tools like Jenkins and deployed to a single server, which means that even small changes affect the entire application.

You can think of a monolithic application like a Jenga tower. All the blocks are stacked together, and each one depends on the others for stability. If you remove or change just one block, for example, a part of the backend or database, the entire application could break, just like the tower collapsing. This shows why monolithic apps are fragile and harder to scale as they grow

Why I Thought My 3-Tier App Was a Microservice

For the longest time, I believed my 3-tier CRUD apps were microservices. On the surface, it looked like I had independent services. There was a frontend running in React, a backend API layer in Spring Boot, and a MySQL database. Each layer ran in its own Docker container, communicating with the others through REST APIs. To me, this seemed like the perfect example of microservices in action.

Looking back, I feel like a dumbass. I had confused containers and APIs with true microservices. Just because something runs separately in Docker does not mean it is independently deployable or truly independent.

What Are Microservices?

A microservices architecture is a way of building applications as a collection of small, independent services, each responsible for a single feature or business capability. Each service:

Has its own codebase and can be deployed independently.
Can have its own database or data storage.
Communicates with other services through APIs or messaging systems.
Can be built using different technologies depending on what fits best.

In a microservices architecture, different teams such as the Accounts Dev Team, Loans Dev Team, Cards Dev Team, and the UI/UX Dev Team each own their own independent service and codebase. Each team can build, test, and deploy their service without waiting for others. These services are usually deployed in containers or cloud environments, often with their own databases, and communicate with other services using APIs or messaging systems. This means that small changes in one service do not require redeploying the entire application, and updates can be rolled out more frequently and independently.

Think of it like a team of specialized chefs in a restaurant. Each chef focuses on a single dish and can cook independently. If the pastry chef is busy, the rest of the kitchen can still function. In contrast, a monolithic app is like one chef trying to cook all dishes at the same time; if they get sick, the whole restaurant suffers.

Microservices make applications more scalable, resilient, and easier to maintain at large scale, but they also introduce extra complexity, like communication between services and monitoring.

Why My 3-Tier App Was Still Monolithic

Even though I had three separate layers, my application was still monolithic because:

All the backend logic lived in a single codebase.
The frontend, backend, and database were tightly coupled.
If one part failed, it could affect the whole system.
Any schema changes in the database or major updates in the backend could break other parts of the application.
Scaling was limited. I could scale the backend as a whole, but I could not scale individual features or services independently.

In contrast, microservices allow you to scale each service based on its own needs.

The Real Difference

Here is a small table that will help you differentiate between Monolithic and Microservices Architecture:

A true microservice is independently deployable, owns its own data, and communicates with other services via APIs. One service can fail, be updated, or scaled without affecting the others. My 3-tier apps, no matter how nicely divided into frontend, backend, and database layers, were still a single, unified application. They were layered, not independent.

A Simple Thumb Rule

If it scales and deploys as one unit, it’s monolithic. If it scales and deploys in parts, it’s microservices.

Takeaways

The words layers and services can be confusing. The important lesson is understanding the difference now and knowing that separation alone does not make an application a microservice. Running things in Docker and communicating via APIs is useful, but it does not automatically make your app a microservice.

The real takeaway is that learning architecture is a journey. Mistakes like this are part of the process, and understanding them makes you a better developer. At the same time, it is worth remembering that microservices are not perfect either. They introduce added complexity with service-to-service communication, monitoring, testing, and deployment pipelines. Choosing between monolithic and microservices should always depend on the scale and needs of the application.