Explain Spring Boot startup flow.

Hook: Spring Boot startup is like opening a restaurant: the kitchen is stocked first, the doors unlock next, and only then do customers walk in.

Question: Explain Spring Boot startup flow.

Answer: Spring Boot startup begins in the main() method when you call SpringApplication.run(...). Boot then prepares the environment, creates the application context, loads beans and auto-configuration, refreshes the context, starts the embedded server for web apps, and finally runs startup hooks like ApplicationRunner and CommandLineRunner. If everything succeeds, it publishes an "app is ready" event and returns the running context.

Interview-Ready Answer: "I start with main() calling SpringApplication.run(). Spring Boot first prepares the Environment from config files, profiles, and command-line args, then creates the right ApplicationContext, scans and registers beans, applies auto-configuration, and refreshes the context so singletons get created. In a web app, the embedded server starts during that refresh. After the context is up, Boot runs ApplicationRunner and CommandLineRunner, and if none of those fail, it publishes ApplicationReadyEvent. A detail I like to mention is that in Boot 3, auto-configuration metadata comes from META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports, not the old Boot 2 spring.factories path."

What startup flow really means

Startup flow is the ordered path from a plain Java process to a live Spring app. The key idea is that Boot does not just "start a server"; it builds a full dependency graph, wires beans, applies defaults, and only then marks the app as ready.

Under the hood: the numbered flow

1. main() calls SpringApplication.run(). This is the entry point. Boot now owns the rest of the bootstrap process.
2. Boot figures out the app type. It decides whether the app is servlet-based, reactive, or non-web based on the classpath. This choice determines whether Tomcat, Jetty, Netty, or no server is started.
3. The Environment is prepared. The Environment is the object that holds properties. Boot loads application.properties or application.yml, profile-specific files like application-prod.yml, system properties, environment variables, and command-line arguments, then merges them by precedence.
4. Listeners and startup events are set up. Boot publishes early lifecycle events so tooling and custom listeners can observe startup. This is why you can log or inspect startup phases without changing core framework code.
5. The correct ApplicationContext is created. For a servlet app this is usually a ServletWebServerApplicationContext; for a reactive app it is a reactive web context; for a non-web app it is a plain application context. The context is the container that stores bean definitions and bean instances.
6. Sources are loaded and auto-configuration is applied. Your @SpringBootApplication class includes @ComponentScan and @EnableAutoConfiguration. Component scanning finds your beans; auto-configuration adds sensible defaults only when the classpath and existing beans match conditions such as @ConditionalOnClass or @ConditionalOnMissingBean.
7. The context is refreshed. refresh() is the big moment. Spring creates bean factories, runs bean factory post-processors, instantiates singleton beans, performs dependency injection, calls lifecycle callbacks like @PostConstruct, and resolves most wiring problems here. If a required bean is missing or a constructor throws, startup fails now.
8. The web server starts during refresh for web apps. Embedded Tomcat, Jetty, or Netty is started as part of the context refresh, so the process is already listening on the configured port before the app is marked fully ready.
9. Post-start hooks run. After the context is alive, Boot calls ApplicationRunner and CommandLineRunner. These are good for small startup tasks like validation, warmup, or logging, but not for long blocking work.
10. Boot publishes readiness. Finally, ApplicationReadyEvent is published. At this point the app is considered ready to serve traffic, and SpringApplication.run() returns the live context.

Runner types: a tiny but important comparison

Boot 2 vs Boot 3 note: older Boot 2 auto-configuration metadata came from spring.factories; Boot 3 uses the dedicated AutoConfiguration.imports file. The startup idea is the same, but the discovery mechanism changed.

Why this order matters

You want configuration first, beans second, server third, and business hooks last. If you try to do heavy work too early, the container is not ready; if you do it too late, you delay readiness and make deployments slow. The flow exists to keep startup deterministic and failure visible.

Performance and edge cases

Startup cost is roughly proportional to the number of beans and the amount of classpath scanning, so think of it as O(B + C) in practice, where B is bean count and C is metadata scanning. Small services often start in a few hundred milliseconds to a couple of seconds; large enterprise apps with many starters can take 5–15 seconds or more. Lazy initialization can reduce startup time, but it pushes failures to first request time.

• If a constructor, @PostConstruct, or bean factory method throws, refresh fails immediately.
• If a runner throws, the app can fail after the context is already built, which often confuses people during debugging.
• If a bean is marked @Lazy, it may not be created during startup at all.
• For web apps, the server starts before ApplicationReadyEvent, but after the core context refresh begins.

Memory hook: "Passport, gate, boarding": first Boot checks the passport (Environment), then opens the gate (refresh()), then boards passengers (Runners).

Real-World Story: Imagine a checkout service in an e-commerce platform. On startup it loads payment config, connects to the database, warms a small cache, and then becomes ready for traffic. A developer once put a remote call to a flaky pricing service inside a CommandLineRunner, because it "felt like startup work." In Kubernetes, every pod spent 20–30 seconds waiting, readiness probes timed out, and the deployment never became healthy. The logs showed the app had created the context, then ended with Application run failed when the runner threw. Customers saw 503 errors because no pod ever reached ready state.

The fix was to keep startup fast, move the expensive call to an async background job after ApplicationReadyEvent, and add a timeout plus fallback. That change made the service start in under 2 seconds again and stopped the rollout failures.

What went wrong technically: the team confused "context is built" with "the app is safe to block on network calls." Startup hooks are still part of the critical path, so a slow or failing dependency can break deployment even if the code looks harmless.

Follow-up & Tricky Questions:

• What runs first: @PostConstruct, ApplicationRunner, or ApplicationReadyEvent? @PostConstruct runs during bean creation inside context refresh, then the runners execute, and only after that does ApplicationReadyEvent fire.
• Why does @SpringBootApplication matter in startup flow? It bundles component scanning and auto-configuration, so it is the main reason Boot can discover your beans and apply defaults automatically.
• What happens if a runner throws an exception? Startup fails even if the context was already created; in a web app, the server may have started briefly and then the process shuts down because the application never became ready.
• How does Boot find auto-configuration classes? Boot loads metadata from its auto-configuration import file and then filters those classes through conditions like classpath presence and missing-bean checks.
• How do you reduce startup time? Trim unnecessary starters, remove heavy scans, use lazy init carefully, avoid expensive logic in constructors and runners, and keep remote calls out of the critical path.
• Tricky: Does ApplicationReadyEvent mean the app can never fail again? No. It only means startup finished successfully; the app can still fail later because of runtime exceptions, dead dependencies, or resource exhaustion.
• Tricky: Is CommandLineRunner safer than ApplicationRunner? No. They both run after context refresh and can both abort startup; the real difference is how they receive arguments, not when they run.
• Tricky: Are lazy beans created during startup? Not necessarily. A @Lazy bean is skipped until something asks for it, which can hide startup failures until the first request.

Common Mistakes:

• Mistake: Saying Boot "creates beans in main()." Correction: main() only hands control to SpringApplication.run(); the container creates beans later during refresh.
• Mistake: Thinking runners run before the context is ready. Correction: They run after refresh, so the bean graph already exists.
• Mistake: Putting slow network calls in startup hooks. Correction: Keep startup fast and move expensive work to background jobs or async tasks.
• Mistake: Forgetting that auto-configuration is conditional. Correction: Boot only configures what matches the classpath and your existing beans.

Memory Hook: Think "passport, gate, boarding": Boot checks the Environment, opens the container gate with refresh, then boards the runners.

Cheat Sheet:

• main() calls SpringApplication.run().
• Boot prepares the Environment first.
• Then it creates and refreshes the ApplicationContext.
• Auto-configuration fills in defaults conditionally.
• Embedded server starts during refresh in web apps.
• ApplicationRunner and CommandLineRunner run after startup, then ApplicationReadyEvent fires.

Practice Tasks:

• Run a tiny Boot app and add log statements for ApplicationStartedEvent and ApplicationReadyEvent.
• Add demo.fail=true and observe how a runner can abort startup.
• Compare startup time before and after removing an unnecessary starter or enabling lazy initialization.