Custom Spring Boot Starter.

Interviewers like this question because it reveals whether you can turn a reusable feature into a one-line dependency instead of copying setup into every app.

Question: What is a custom Spring Boot starter?

Answer: A custom starter is a packaged way to add a feature to many Spring Boot apps with very little code in each app. It usually combines an auto-configuration module, default beans, and a starter dependency that pulls in the right libraries. Spring Boot creates the defaults only when the needed classes exist and the application has not already provided its own bean.

Interview-Ready Answer: I would say a custom Spring Boot starter is a reusable package that lets me add a feature with one dependency instead of hand wiring everything. In practice, I split it into a starter artifact that brings in dependencies and an auto-configuration jar that creates beans with conditions like @ConditionalOnClass and @ConditionalOnMissingBean. That gives safe defaults, but still lets the application override them cleanly. In Spring Boot 3, the auto-configuration class is usually registered through META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports.

What it is

A custom Spring Boot starter is not magic; it is a packaging pattern. The starter gives the consumer a single dependency, while the auto-configuration module decides what beans to create based on the classpath, properties, and existing user beans. Think of it as a safe default kit: it helps every app behave the same way without forcing one app-specific design on everyone.

How it works under the hood

1. You build the reusable feature as a library. This is the code that knows how to talk to your payment gateway, cache, mail server, metrics system, or any other shared tool.
2. You add auto-configuration. A class such as @Configuration or @AutoConfiguration creates beans only when conditions match. Common conditions are @ConditionalOnClass for classpath presence, @ConditionalOnProperty for opt-in or opt-out behavior, and @ConditionalOnMissingBean for back-off.
3. You register the auto-configuration. In Spring Boot 3.x, the registration file is META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. In Boot 2.7 and earlier, the older mechanism was META-INF/spring.factories.
4. You publish a starter artifact. The starter is usually a thin POM or Gradle module that pulls in the library and any third-party dependencies the feature needs. The starter itself should stay small; it should not contain business logic.
5. The application adds one dependency. When the app starts, Boot reads the auto-configuration metadata before the context is refreshed, evaluates the conditions, and creates only the beans that are safe and relevant for that app.

Starter vs auto-configuration vs plain library

When and why to use it

Use a custom starter when many services need the same setup and you want them to start with sane defaults: logging, tracing, messaging, security helpers, clients, or SDK wrappers. Do not use a starter for one tiny app-specific feature; that just hides complexity in another jar. The real win is consistency: every service gets the same default behavior, while each app can still override it with its own bean or property.

Performance, defaults, and edge cases

The cost is mostly at startup, not at request time. Condition checks are roughly O(n) in the number of auto-configuration classes, but each check is small and the runtime cost after the beans are created is just normal Spring bean usage. Keep bean creation cheap: do not open sockets, hit databases, or call remote services in a starter constructor. Also remember that @ConditionalOnProperty defaults to off unless you set matchIfMissing = true, and proxyBeanMethods = false is often used to reduce startup overhead when configuration methods do not call each other.

Real edge cases: if you forget @ConditionalOnMissingBean, your starter may override user beans by accident; if you forget @ConditionalOnClass, the app can fail on startup when a third-party library is absent; and if one starter depends on another, you may need ordering hints so Boot evaluates them in the right sequence. A good mental rule is: defaults should be helpful, never bossy.

Version note: Spring Boot 3 favors the new imports file, which is clearer and AOT-friendly. Boot 2.7 and older used spring.factories; interviewers like to hear that you know both, because many older codebases still use the old style.

Real-World Story: A checkout service at an e-commerce company used an internal payments-spring-boot-starter to wire a gateway client, retry policy, and metrics. A developer removed @ConditionalOnClass by mistake, so the payment bean tried to load on services that did not even ship the gateway SDK. Deploys started failing with NoClassDefFoundError and UnsatisfiedDependencyException, pods went into CrashLoopBackOff, and users saw checkout time out until the release was rolled back.

What went wrong: The team treated the starter like ordinary app code instead of guarded infrastructure. The symptoms were startup failures, repeated restart logs, and missing checkout traffic; the fix was to restore the classpath condition and add a test that boots the app with the dependency removed.

Follow-up & Tricky Questions:

• How is a custom starter different from auto-configuration? A starter is usually the dependency bundle that pulls everything in, while auto-configuration is the code that creates beans and applies conditions. Many real projects ship both, but they solve different parts of the problem.
• What files do you need for a Spring Boot 3 starter? You usually need an auto-configuration class plus META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. The starter module itself is often just a thin dependency wrapper.
• How do you let application code override the starter default? Put the default bean behind @ConditionalOnMissingBean. That makes the starter back off when the app defines its own bean of the same type.
• How do you disable a starter feature? Add a property condition such as @ConditionalOnProperty and turn the property off. This is better than forcing consumers to exclude classes or edit internal code.
• How do you test a starter? Use ApplicationContextRunner or a small Boot test to check the bean appears with the right classpath and disappears when the property is off. You should always test both the enabled path and the back-off path.
• Do I need component scanning in a starter? Usually no. Component scanning can pull in too much and make the starter noisy; explicit auto-configuration is more predictable and safer for consumers.
• Can a starter contain business logic? It can contain tiny helper logic, but it should mostly provide wiring, defaults, and integration points. Real business rules belong in the application or a separate library.
• If the app defines the same bean, what happens? With @ConditionalOnMissingBean, the app wins and the starter backs off. Without that condition, the starter may override the app or cause ambiguity.
• Tricky: Is a starter the same thing as a library? No. A library gives you classes to call, while a starter makes Spring Boot auto-create and configure beans for you. A starter often includes a library, but it adds the Boot integration layer.
• Tricky: Will the starter load if the needed third-party class is missing? It should not, if you used @ConditionalOnClass. That condition is one of the main safety rails that keeps optional integrations from breaking unrelated apps.

Common Mistakes:

• Putting too much logic in the starter. Correction: keep the starter thin; it should wire and configure, not own the feature’s core behavior.
• Forgetting conditional annotations. Correction: use @ConditionalOnClass, @ConditionalOnProperty, and @ConditionalOnMissingBean so the starter is safe and optional.
• Using component scan inside the starter. Correction: prefer explicit auto-configuration so the starter does not accidentally pull in unrelated beans from the consumer app.
• Not testing the override path. Correction: add tests that prove the default bean appears, disappears, and backs off when the app provides its own bean.

Memory Hook: Think of a custom starter as a power strip: the starter POM brings the outlets, auto-configuration flips the switch, and @ConditionalOnMissingBean lets the user unplug your lamp and plug in their own.

Cheat Sheet:

• Starter = dependency bundle for easy adoption.
• Auto-config = bean wiring with conditions.
• Boot 3 uses AutoConfiguration.imports; Boot 2.7 used spring.factories.
• Use @ConditionalOnMissingBean so apps can override defaults.
• Use @ConditionalOnClass to protect optional integrations.
• Keep bean creation cheap and startup-friendly.

Practice Tasks:

1. Create a tiny starter that exposes a Clock bean with a configurable timezone.
2. Add a test that disables the feature with a property and verifies the bean is absent.
3. Add a custom application bean and verify the starter backs off without breaking startup.