How does Component Scanning work?

Interviewers love this question because one wrong package or missing annotation can make a bean silently disappear.

Question: How does Component Scanning work?

Answer: Component scanning is Spring Boot’s way of finding classes in your codebase that should become Spring beans. It starts from the package of your main application class, looks for stereotypes like @Component, @Service, @Repository, and @Controller, and registers those classes in the application context. After that, Spring can inject them into each other by constructor or field injection.

Interview-Ready Answer: In Spring Boot, component scanning starts from the package of the class annotated with @SpringBootApplication, because that annotation includes @ComponentScan. Spring walks the classpath under that package, finds stereotype annotations like @Component, turns those classes into bean definitions, and then creates and wires them during context startup. A useful detail is that anything outside the base package is ignored unless I expand the scan with scanBasePackages or scanBasePackageClasses.

What Spring is actually doing

@SpringBootApplication is a meta-annotation, which means it is an annotation made from other annotations. One of those is @ComponentScan. That is why Boot can find your beans without you writing scan configuration in most apps. By default, Spring uses the package of your main class as the root and scans that package plus all subpackages.

How it works under the hood

1. Spring Boot starts from the package that contains the main application class.
2. It builds a set of base packages to scan. If you do nothing, that set usually contains one package: the main class package.
3. Spring walks the classpath and looks for candidate classes in those packages. In simple words, it checks which class files are available under that area of your code.
4. It filters for stereotype annotations such as @Component, @Service, @Repository, @Controller, and @Configuration.
5. For each match, Spring creates a bean definition. A bean definition is the internal blueprint that says what the bean is, how to build it, and how to scope it.
6. During application context refresh, Spring instantiates singleton beans, resolves constructor arguments, and injects dependencies.
7. If a bean is outside the scanned packages, Spring never sees it, so dependency injection fails with an error like NoSuchBeanDefinitionException.

When to use it

Use component scanning when classes belong to the same application and you want low-boilerplate wiring. It is ideal for services, repositories, controllers, helpers, and configuration classes that naturally live under one root package. It is less ideal for third-party objects or classes that need custom construction logic, because those are usually better registered with @Bean methods.

Component scanning vs @Bean

Performance and edge cases

Scanning is a startup-time cost, not a per-request cost. In small apps it is usually tiny, but in large monoliths with thousands of classes it can add noticeable startup time, often hundreds of milliseconds or more. Think of it as roughly linear work over the classes under the scanned packages, so a larger package tree usually means more startup work. Spring can optimize this in some builds with a generated component index, but the mental model is still: find candidates once, then wire them.

• If your main class sits in a narrow package, sibling packages are not scanned.
• If a class has no stereotype annotation, component scanning ignores it.
• If two scanned beans share the same type and you inject by type only, you may need @Qualifier or @Primary.
• @Repository is treated like a component, but it also helps with persistence exception translation.

Best practice: place your main application class in a top-level package like com.example, so all feature packages sit underneath it. If you must scan elsewhere, use @SpringBootApplication(scanBasePackages = ...) or scanBasePackageClasses for a type-safe option.

Real-world story

Imagine a checkout service for an e-commerce app. The team moves PaymentGatewayClient into a shared package so other services can reuse it, but they forget that the Spring Boot main class still scans only the old root package. The app starts, then fails while creating the checkout controller because the payment client bean cannot be found.

What goes wrong: startup logs show a constructor injection failure such as Parameter 0 of constructor ... required a bean of type ... or No qualifying bean of type ... available. Health checks never go green, pods restart, and users see checkout timeouts or 500 errors. The bug is not in business logic; it is a package layout problem that prevented component scanning from seeing the bean.

The fix is usually simple: move the main application class to a higher root package, expand the scan base package, or register the object explicitly with @Bean. That is why scanning is a packaging rule as much as it is an IoC feature.

Follow-up & Tricky Questions:

• What annotations does component scanning pick up? It looks for stereotype annotations such as @Component, @Service, @Repository, @Controller, and @Configuration. The important idea is that these are all bean candidates, but they may have extra behavior on top of being plain components.
• How do you scan a different package? Use @SpringBootApplication(scanBasePackages = ...) or @ComponentScan(basePackages = ...). I prefer moving the main class to a higher root package if possible, because that keeps configuration simpler.
• Is component scanning the same as auto-configuration? No. Component scanning finds your own classes; auto-configuration wires Spring Boot’s infrastructure beans based on the classpath and properties.
• What is the difference between @Component and @Bean? @Component says Spring should discover the class automatically, while @Bean says I want to create and register this object explicitly from a configuration method.
• When does scanning happen? It happens during application startup, before the context is fully refreshed. It is a one-time discovery step, not something that runs on every request.
• How do include and exclude filters work? They let you narrow what the scanner accepts, which is useful when you want to include only certain types or skip test, legacy, or infrastructure classes.
• Does component scanning look in parent packages? No. That is a common trap. It scans the base package and subpackages only, so putting the main class too deep can hide siblings from Spring.
• Are @Bean methods themselves found by component scanning? No. The configuration class containing them may be scanned, but the bean methods are processed separately by Spring once that configuration class is registered.
• Tricky: Is @Repository just a renamed @Component? Not quite. It is still a component, but Spring also uses it as a persistence stereotype and can apply exception translation for data-access errors.
• Tricky: If a class has @Component but is outside the base package, will Spring find it? No. Annotation alone is not enough; the package has to be inside the scan path or explicitly added.
• Tricky: Does scanning create beans immediately? It discovers candidates first, then beans are instantiated later during context refresh, unless a bean is lazy or otherwise deferred.

Common Mistakes:

• Putting the main application class in a deep package. Correction: place it near the package root so all feature packages are scanned.
• Forgetting to annotate a class and expecting Spring to find it anyway. Correction: add a stereotype annotation or register it with @Bean.
• Using only type-based injection when multiple beans of the same type exist. Correction: use @Qualifier or @Primary.
• Thinking component scanning and auto-configuration are the same thing. Correction: scanning finds your beans; auto-configuration creates Boot infrastructure beans.

Memory Hook: Think of Spring scanning like a librarian checking only the shelves in one section of the library: if your book is on that shelf and has the right label, it gets cataloged; if it is in another room, Spring never sees it.

Cheat Sheet:

• @SpringBootApplication includes @ComponentScan.
• Default scan root = package of the main application class.
• Spring finds stereotype annotations and turns them into bean definitions.
• Scanning happens at startup, not per request.
• Use @Bean for third-party or custom-created objects.
• Use scanBasePackages or scanBasePackageClasses when the default root is not enough.

Practice Tasks:

• Move the main class to a deeper package and observe which beans stop loading.
• Add a new @Service in a subpackage and confirm it is injected automatically.
• Replace a scanned bean with an explicit @Bean method and compare the startup behavior.