Explain @ConditionalOnMissingBean.

Hook: This is Spring Boot’s “backup singer” rule: only step on stage when no main singer is already there.

Question: Explain @ConditionalOnMissingBean.

Answer: @ConditionalOnMissingBean tells Spring Boot to create a bean only if the application context does not already contain a matching bean. It is most often used in auto-configuration to provide a safe default that users can override by defining their own bean. The check happens during startup against bean definitions, not later at request time.

Interview-Ready Answer: “I use @ConditionalOnMissingBean when I want Spring Boot to back off and create a default only if the user hasn’t already provided their own bean. It’s one of the main auto-configuration patterns: Boot checks the bean registry during startup, and if a matching bean is already present, it skips the fallback. That’s how starters give sensible defaults without blocking application-level customization.”

What it is

Detailed Explanation: Think of @ConditionalOnMissingBean as a back-off switch. A starter or auto-configuration class says, “I will create a default bean only if nobody else already registered one of the same kind.” The “same kind” is usually a type, but it can also be a specific bean name if you want tighter control.

How it works under the hood

1. Spring Boot parses configuration classes and bean methods during startup, before the application begins serving traffic.
2. The condition is evaluated by Boot’s bean-condition logic against the bean definitions already known to the container. A bean definition is the metadata for a bean before the object is actually created.
3. If no matching bean is found in the current context, Boot registers the fallback bean definition.
4. If a matching bean already exists, the conditional method or configuration class is skipped completely.
5. Later, when the context is refreshed, only the registered beans are instantiated.

This is why the annotation is perfect for defaults in libraries and starters. It is not a runtime if statement, and it is not checking live objects on every request. It is a startup-time decision.

Where to use it

• Auto-configuration: provide a default DataSource-adjacent helper, mapper, client, or strategy.
• Library starters: let application code replace your default by defining its own bean.
• Fallback behavior: create a no-op or simple implementation for local development or minimal setups.

If the app absolutely requires a bean, do not hide the problem with a conditional default. In that case, fail fast or use @ConditionalOnBean on the consumer side so missing dependencies are obvious.

Comparison with nearby annotations

The important difference is this: @ConditionalOnMissingBean controls whether the bean is registered, while @Primary controls which bean is selected when several already exist. A common interview trap is thinking they solve the same problem. They do not.

Important edge cases

1. It checks definitions, not values. If a bean definition exists, the fallback is skipped even if that bean is a proxy or a special implementation.
2. Parent contexts matter. Boot can search ancestor contexts too, so a bean in a parent can suppress a child-context fallback.
3. Order matters conceptually, not textually. You should not rely on method order inside a class; rely on proper auto-configuration structure.
4. It is startup-only. Adding a bean after the context is refreshed is too late to influence the condition.
5. It is common in Boot 2.x and 3.x. The core behavior is stable; the main difference across modern Boot versions is surrounding infrastructure, not this idea itself.

Memory Hook: “If the VIP is already in the room, the backup singer stays backstage.” That is the whole mental model.

Performance note: The cost is usually small and happens once at startup. It is roughly linear in the number of bean definitions Spring must inspect, so in a typical app with hundreds or even a few thousand beans, it is startup noise, not request-time overhead.

Real-World Example: A checkout service had a FraudCheckClient starter. In local dev, the starter should provide a simple no-op fallback, but production apps can replace it with a real partner implementation. One release forgot the missing-bean guard, so both the default client and the tenant-specific client were created. Pods started crash-looping with NoUniqueBeanDefinitionException, Kubernetes kept restarting them, and checkout traffic returned 503s because the app never finished booting. The fix was to make the fallback bean conditional so the tenant bean could win cleanly.

The subtle lesson: @ConditionalOnMissingBean is how library authors say, “I will be helpful by default, but I will never fight the application for control.”

Follow-up & Tricky Questions:

• How does it differ from @ConditionalOnBean? @ConditionalOnBean creates something only when a dependency exists; @ConditionalOnMissingBean creates a fallback when it does not. They are opposites and often appear together in auto-configuration.
• What does it match by default? When used on a @Bean method, it usually checks the bean method’s return type unless you specify a more exact type or name. That is why picking the right return type matters.
• Does @Primary affect the condition? No. @Primary helps Spring choose a bean during injection, but @ConditionalOnMissingBean only cares whether a matching bean exists at registration time.
• Can it see beans in parent contexts? Yes, parent or ancestor context beans can suppress the fallback, which is important in layered apps and some test setups.
• Should I use it in business logic? Usually no. It is best for framework defaults and starter code, not for per-request decisions or feature flags.
• Tricky: If I already have two beans and one is @Primary, will the fallback still be created? No. The fallback backs off as soon as any matching bean exists; @Primary only affects which existing bean gets injected.
• Tricky: Does source-code order of methods decide whether the condition works? No. Spring works from configuration processing and bean registration, not from the visual order of methods on the page. Do not depend on method order as a control mechanism.
• Tricky: If I register a bean after the context is refreshed, will the condition notice it? No. The condition is evaluated during startup, so late bean registration cannot retroactively change whether the fallback bean was created.

Common Mistakes:

• Thinking it is runtime logic. Correction: it runs during startup when Spring builds the bean registry.
• Using the wrong type. Correction: match the interface or bean name you really want to protect; an overly broad type can suppress the fallback unexpectedly.
• Confusing it with @Primary. Correction: @Primary resolves ambiguity after beans exist; @ConditionalOnMissingBean prevents the fallback from being registered in the first place.
• Forgetting parent contexts. Correction: a bean in an ancestor context can cause the condition to back off, which can surprise tests and layered applications.

Memory Hook: “VIP first, backup later.” If the application already brought the VIP bean, Spring Boot politely keeps the backup bean off the stage.

Cheat Sheet:

• Use it for defaults, not mandatory dependencies.
• It checks the bean registry at startup.
• It is the standard back-off pattern in Boot starters.
• @ConditionalOnBean = create when present; @ConditionalOnMissingBean = create when absent.
• @Primary chooses a winner; it does not stop bean creation.

Practice Tasks:

• Build a default Clock bean that only appears when the app does not define one.
• Add a custom implementation and verify that the default backs off.
• Create two beans of the same type, remove @Primary, and observe the ambiguity error at injection time.