How does Spring Dependency Injection actually work?

Spring Dependency Injection means your class does not create its own dependencies. Instead, it declares what it needs, and Spring provides those dependencies when it creates the object.

The important idea is this: your application code no longer controls object creation directly. Spring's container does.

Imagine a service class that needs a repository, a validator, a clock, a metrics recorder, and maybe a client for another API.

Without dependency injection, code often turns into this:

public class OrderService {
    private final OrderRepository repository = new OrderRepository();
    private final PaymentClient paymentClient = new PaymentClient();
    private final MetricsRecorder metrics = new MetricsRecorder();

    public void placeOrder(Order order) {
        // business logic
    }
}

This looks simple at first, but the class is now tightly coupled to concrete implementations. Testing is harder, replacing dependencies is harder, and configuration becomes scattered everywhere.

At a high level, Spring Boot starts the application, scans for components, builds bean definitions, creates beans, resolves their dependencies, and wires everything together.

This is why a class annotated with @Service can be injected into a controller without you manually creating it. Spring discovered it, registered it as a bean, and made it available to other beans.

Constructor injection is usually the cleanest way to express required dependencies.

@Service
public class OrderService {
    private final OrderRepository repository;
    private final PaymentClient paymentClient;

    public OrderService(
            OrderRepository repository,
            PaymentClient paymentClient
    ) {
        this.repository = repository;
        this.paymentClient = paymentClient;
    }

    public void placeOrder(Order order) {
        // business logic
    }
}

Notice that OrderService does not call new OrderRepository(). It simply declares what it needs.

Spring looks inside its application context for a matching bean. If the constructor needs an OrderRepository, Spring searches for a bean of that type.

@Repository
public class JpaOrderRepository implements OrderRepository {
    // database logic
}

Because this class is annotated with @Repository, component scanning can discover it and register it as a bean.

These annotations all register classes as Spring-managed beans, but they communicate intent.

For interview purposes, it is useful to say that these are stereotype annotations. They help Spring discover beans and help humans understand the role of a class.

Use @Component when the class is yours and can be annotated directly.

Use @Bean when you want to create a bean manually, often for third-party classes or configuration-heavy objects.

@Configuration
public class AppConfig {

    @Bean
    public Clock clock() {
        return Clock.systemUTC();
    }
}

Here, Clock is not your custom Spring component. You are telling Spring: “Call this method and register the returned object as a bean.”

It can feel like magic because you do not call constructors manually. But the idea is straightforward:

If Spring finds exactly one matching bean, injection is simple. If it finds multiple candidates, it needs help deciding.

You can resolve ambiguity with names, qualifiers, or primary beans.

@Service
public class NotificationService {
    private final MessageSender sender;

    public NotificationService(
            @Qualifier("emailSender") MessageSender sender
    ) {
        this.sender = sender;
    }
}