Spring Boot Interview Questions

Every Spring interview opens here. The trick is not to recite "IoC means inversion of control" — interviewers have heard that line a thousand times. They want to see if you understand what got inverted and why it matters in real code.

The "inversion" in plain English

Without IoC, your class controls its dependencies — it new's them up directly. With IoC, that control is inverted: a container creates the dependencies and hands them to your class. Your class just declares "I need a PaymentGateway" — it doesn't pick which implementation, doesn't construct it, doesn't manage its lifecycle.

Dependency Injection is one specific technique to achieve IoC — handing dependencies in via the constructor, a setter, or a field, rather than letting the class build them itself.

class CheckoutService {
    private RazorpayClient rp = new RazorpayClient();   // hard-coded

    public void pay(Order o) { rp.charge(o.amount); }
}

@Service
class CheckoutService {
    private final PaymentGateway gw;

    public CheckoutService(PaymentGateway gw) {   // Spring will inject
        this.gw = gw;
    }

    public void pay(Order o) { gw.charge(o.amount); }
}

Why this matters beyond aesthetics

• Testability. In a unit test, hand in a FakePaymentGateway instead of a real one. No mocking framework needed.
• Swappability. Switch from Razorpay to Stripe by changing a configuration line, not 200 source files.
• Lifecycle management. The container decides when to create, share, and destroy beans — singleton vs request-scoped, eager vs lazy, etc.
• Cross-cutting concerns. Because beans go through the container, Spring can wrap them with proxies for transactions, security, caching, async — without your code knowing.

The two interfaces

• BeanFactory — the original, low-level container. Lazy by default (creates beans only when first asked). Knows about beans and their wiring, nothing more.
• ApplicationContext — the grown-up superset. Extends BeanFactory and adds: event publishing, internationalization, environment abstraction, AOP integration, eager singleton instantiation by default, and resource loading.

Common ApplicationContext implementations

The five built-in scopes

@Component
@Scope("prototype")
class ReportBuilder { /* fresh instance per request */ }

@Component
@RequestScope
class UserContext { private String userId; }

The full sequence (singleton scope)

1. Class detection. Component scan finds @Component, @Service, @Configuration, etc., or you declare a @Bean method.
2. Bean definition registered. Spring stores metadata (class, scope, dependencies) in a BeanDefinition.
3. Instantiation. Spring calls the constructor, passing in any constructor-injected dependencies.
4. Property population. Setters and field injection happen.
5. Aware callbacks. If the bean implements BeanNameAware, ApplicationContextAware, etc., those are called.
6. BeanPostProcessor.postProcessBeforeInitialization() — registered post-processors get a shot. AOP proxy creation happens here.
7. Initialization. @PostConstruct, then InitializingBean.afterPropertiesSet(), then any custom init-method.
8. BeanPostProcessor.postProcessAfterInitialization() — final wrapping.
9. Bean in use. Application code injects/uses the bean.
10. Container shutdown. @PreDestroy, then DisposableBean.destroy(), then any custom destroy-method.

@Component
class ConnectionPool {

    @PostConstruct
    public void warmUp() {
        // open connections, prefetch metadata, etc.
    }

    @PreDestroy
    public void drain() {
        // close connections cleanly
    }
}

Functionally? Mostly the same. Semantically? Different roles.

All four register the class as a Spring bean. The differences are intent signaling + a few specific behaviors:

• @Component — generic Spring-managed bean. The base annotation; the others are specializations.
• @Service — marker for the service layer (business logic). Same as @Component at runtime, but tells readers "this is where the logic lives."
• @Repository — marker for the persistence layer. Spring auto-translates JDBC/JPA exceptions into DataAccessException — that's a real behavioral difference.
• @Controller — marker for an MVC controller. Spring MVC's DispatcherServlet looks for these to dispatch HTTP requests.
• @RestController = @Controller + @ResponseBody — every method's return value is serialized to JSON, no view resolution.

The three styles

// 1. Constructor injection — the recommended way
@Service
class CheckoutService {
    private final PaymentGateway gw;
    private final OrderRepository orders;

    public CheckoutService(PaymentGateway gw, OrderRepository orders) {
        this.gw = gw;
        this.orders = orders;
    }
}

// 2. Setter injection — for optional dependencies
@Service
class EmailService {
    private MetricsClient metrics;

    @Autowired(required = false)
    public void setMetrics(MetricsClient m) { this.metrics = m; }
}

// 3. Field injection — convenient, but considered an anti-pattern
@Service
class UserService {
    @Autowired
    private UserRepository repo;
}

Why constructor injection wins

• Final fields = immutability. Compiler enforces that dependencies can't change after construction.
• No partially constructed objects. Object exists only when fully wired.
• Mandatory dependencies are obvious. Anything in the constructor is required; setters are clearly optional.
• Trivial to unit test. new CheckoutService(fakeGw, fakeRepo). No Spring, no reflection.
• Circular dependencies fail loudly at startup, not silently at runtime.
• Since Spring 4.3, the @Autowired annotation is optional if the class has only one constructor.

Three ways to disambiguate

@Service
class CheckoutService {
    public CheckoutService(@Qualifier("stripeGateway") PaymentGateway gw) {
        // Spring picks the bean named "stripeGateway"
    }
}

@Component
@Primary
class RazorpayGateway implements PaymentGateway { }

@Component
class StripeGateway implements PaymentGateway { }

// Anywhere PaymentGateway is injected without @Qualifier → RazorpayGateway wins

@Component
@Profile("prod")
class RazorpayGateway implements PaymentGateway { }

@Component
@Profile({"dev", "test"})
class FakeGateway implements PaymentGateway { }

// Switched via spring.profiles.active=dev or =prod

Combining them — the resolution order

1. Profile filtering happens first — beans for inactive profiles aren't even registered.
2. If exactly one bean of the type is registered → injected.
3. Multiple → @Qualifier if present picks one; else @Primary picks one; else error.

The mechanism, in three layers

1. @SpringBootApplication is a meta-annotation = @Configuration + @ComponentScan + @EnableAutoConfiguration.
2. @EnableAutoConfiguration imports AutoConfigurationImportSelector, which scans every JAR for META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports (Spring Boot 3+) — a plain text file listing config classes to import.
3. Each listed config class is gated with conditions:
   • @ConditionalOnClass — only apply if a class is on the classpath.
   • @ConditionalOnMissingBean — only register if the user hasn't already defined one.
   • @ConditionalOnProperty — only if a property is set.
   • @ConditionalOnWebApplication — only in web apps.

@AutoConfiguration
@ConditionalOnClass(DataSource.class)
@ConditionalOnMissingBean(DataSource.class)
class DataSourceAutoConfiguration {

    @Bean
    @ConfigurationProperties("spring.datasource")
    public DataSource dataSource() { /* HikariCP wired with props */ }
}

Three flags every interviewer will probe

• spring.autoconfigure.exclude=... in properties — disable specific auto-configs.
• @EnableAutoConfiguration(exclude = ...) — same thing, in code.
• --debug on startup — prints the "auto-configuration report": what was matched, what was rejected and why.

Starters in one sentence

A starter is a curated dependency descriptor (a JAR with no code, only a POM) that pulls in everything you need for a feature. spring-boot-starter-web brings in Spring MVC + Tomcat + Jackson + Logback — one dependency, six bundled.

The version magic — spring-boot-starter-parent

Your project inherits from spring-boot-starter-parent, which inherits from spring-boot-dependencies — a giant BOM (Bill of Materials) that specifies the exact compatible version of every Spring-and-related library. So when you write:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
    <!-- <version> intentionally omitted -->
</dependency>

Maven looks up the version from the BOM. The whole point: stop the "library X 4.2 needs library Y 1.6 but Spring needs Y 1.5" hell that Java was famous for.

Common starters worth memorizing

The two ways to read config

@Component
class RetryService {
    @Value("${retry.max-attempts:3}")
    private int maxAttempts;   // 3 is the default if the property is missing
}

@Component
@ConfigurationProperties(prefix = "retry")
class RetryConfig {
    private int maxAttempts = 3;
    private Duration backoff = Duration.ofMillis(200);
    private List<String> retryableErrors;
    // getters and setters omitted
}

Now in application.yml:

retry:
  max-attempts: 5
  backoff: 500ms
  retryable-errors:
    - TIMEOUT
    - CONNECTION_RESET

When to use which

Property source precedence (high to low)

1. Command-line args (--server.port=9000)
2. SPRING_APPLICATION_JSON environment variable
3. OS environment variables
4. External application-<profile>.yml
5. Classpath application-<profile>.yml
6. External application.yml
7. Classpath application.yml
8. @PropertySource annotations
9. Defaults (SpringApplication.setDefaultProperties)

The basics

A profile is a named slice of configuration. You write per-profile YAMLs (application-dev.yml, application-prod.yml) and per-profile beans (@Profile("dev")). Spring activates a profile via spring.profiles.active.

// 1. application.yml
spring:
  profiles:
    active: dev

// 2. JVM arg
-Dspring.profiles.active=prod

// 3. Environment variable
SPRING_PROFILES_ACTIVE=prod

Multi-document YAML (Spring Boot 2.4+)

spring:
  application:
    name: checkout
---
spring:
  config:
    activate:
      on-profile: dev
datasource:
  url: jdbc:h2:mem:test
---
spring:
  config:
    activate:
      on-profile: prod
datasource:
  url: ${PROD_DB_URL}
  username: ${PROD_DB_USER}

The shift from WAR to executable JAR

Pre-Boot, you wrote a WAR and deployed it to an external Tomcat / WebSphere / WildFly. Boot inverted this: the server lives inside your app. spring-boot-starter-web bundles Tomcat as a library; the main() method bootstraps it.

@SpringBootApplication
public class CheckoutApp {
    public static void main(String[] args) {
        SpringApplication.run(CheckoutApp.class, args);
    }
}

What SpringApplication.run() does

1. Creates an ApplicationContext (which one depends on classpath: web vs reactive vs plain).
2. Loads property sources, activates profiles.
3. Runs auto-configuration → registers beans.
4. Component scans starting from the package of the class with @SpringBootApplication.
5. Calls refresh() on the context — instantiates singletons, runs @PostConstruct, starts embedded server.
6. Calls any CommandLineRunner / ApplicationRunner beans.

Switching the server

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <artifactId>spring-boot-starter-jetty</artifactId>
</dependency>

The flow, step by step

1. Tomcat (or your server) accepts the TCP connection, parses HTTP, hands a HttpServletRequest to the registered servlet.
2. Spring Boot registered DispatcherServlet (mapped to /) — it gets the request.
3. HandlerMapping (typically RequestMappingHandlerMapping) looks up the matching @RequestMapping method by URL + method + headers + content type.
4. HandlerAdapter (RequestMappingHandlerAdapter) invokes that method:
   • Resolves arguments via HandlerMethodArgumentResolvers (@PathVariable, @RequestBody, @RequestParam, etc.).
   • Calls your method.
   • Handles the return value via HandlerMethodReturnValueHandlers.
5. If @ResponseBody (or @RestController) — the return value is serialized via an HttpMessageConverter (Jackson for JSON, etc.).
6. If a view name is returned — the ViewResolver resolves it to a view (Thymeleaf, JSP).
7. Any exception → caught by HandlerExceptionResolver chain, which finds the matching @ExceptionHandler or @ControllerAdvice.
8. Response written back through Tomcat to the client.

@RestController
@RequestMapping("/api/v1/orders")
class OrderController {

    private final OrderService svc;
    public OrderController(OrderService svc) { this.svc = svc; }

    @GetMapping("/{id}")
    public OrderDto getOne(@PathVariable String id) {
        return svc.findById(id);
    }

    @GetMapping
    public Page<OrderDto> list(
            @RequestParam(defaultValue = "0") int page,
            @RequestParam(defaultValue = "20") int size,
            @RequestHeader("X-Tenant-Id") String tenant) {
        return svc.list(tenant, page, size);
    }

    @PostMapping
    @ResponseStatus(HttpStatus.CREATED)
    public OrderDto create(@Valid @RequestBody CreateOrderRequest req) {
        return svc.create(req);
    }

    @PutMapping("/{id}")
    public ResponseEntity<OrderDto> update(
            @PathVariable String id,
            @RequestBody UpdateOrderRequest req) {
        OrderDto updated = svc.update(id, req);
        return ResponseEntity.ok().eTag(updated.version()).body(updated);
    }

    @DeleteMapping("/{id}")
    @ResponseStatus(HttpStatus.NO_CONTENT)
    public void delete(@PathVariable String id) { svc.delete(id); }
}

Annotations cheatsheet

When to return ResponseEntity vs a plain DTO

• Plain DTO → simplest, fine for 99% of GETs.
• ResponseEntity → when you need custom headers (ETag, Location), conditional status, or a body that depends on logic (200 vs 304).

The pattern — global advice

@RestControllerAdvice
class GlobalExceptionHandler {

    @ExceptionHandler(EntityNotFoundException.class)
    public ResponseEntity<ProblemDetail> notFound(EntityNotFoundException ex) {
        ProblemDetail p = ProblemDetail.forStatusAndDetail(HttpStatus.NOT_FOUND, ex.getMessage());
        return ResponseEntity.status(HttpStatus.NOT_FOUND).body(p);
    }

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<Map<String, String>> validation(MethodArgumentNotValidException ex) {
        Map<String, String> errors = new HashMap<>();
        ex.getBindingResult().getFieldErrors()
          .forEach(e -> errors.put(e.getField(), e.getDefaultMessage()));
        return ResponseEntity.badRequest().body(errors);
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<ProblemDetail> fallback(Exception ex) {
        log.error("Unhandled", ex);
        return ResponseEntity.status(500)
            .body(ProblemDetail.forStatusAndDetail(HttpStatus.INTERNAL_SERVER_ERROR, "Something went wrong"));
    }
}

ProblemDetail — RFC 7807 (Spring 6+)

Spring 6 / Boot 3 ship ProblemDetail, a built-in type that follows RFC 7807 (Problem Details for HTTP APIs). One standard error shape across services beats every team inventing their own.

{
  "type": "about:blank",
  "title": "Not Found",
  "status": 404,
  "detail": "Order 12345 not found",
  "instance": "/api/v1/orders/12345"
}

The annotations you'll use 95% of the time

record CreateOrderRequest(
        @NotBlank String userId,
        @NotEmpty List<@Valid LineItem> items,
        @Min(1) int quantity
) {}

@PostMapping
public OrderDto create(@Valid @RequestBody CreateOrderRequest req) {
    // if validation fails, MethodArgumentNotValidException is thrown
    // → 400 Bad Request, handled by @ControllerAdvice
}

@Valid vs @Validated

• @Valid — JSR-380 standard. Triggers nested validation.
• @Validated — Spring's variant. Adds group support (validate different rules at different times) and works on method parameters in any Spring bean (not just controllers).

Custom constraint

@Constraint(validatedBy = SkuValidator.class)
@Target({ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
public @interface ValidSku {
    String message() default "invalid SKU";
    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
}

class SkuValidator implements ConstraintValidator<ValidSku, String> {
    public boolean isValid(String sku, ConstraintValidatorContext ctx) {
        return sku != null && sku.matches("[A-Z]{3}-\\d{4}");
    }
}

The three layers, outside-in

@Aspect
@Component
class TimingAspect {

    @Around("@annotation(Timed)")
    public Object time(ProceedingJoinPoint pjp) throws Throwable {
        long start = System.nanoTime();
        try {
            return pjp.proceed();
        } finally {
            log.info("{} took {}ms", pjp.getSignature(),
                (System.nanoTime() - start) / 1_000_000);
        }
    }
}

How Spring AOP actually works

Spring AOP is proxy-based. When the container creates a bean that has methods to advise, it wraps the bean in a proxy object. Callers get the proxy. The proxy intercepts every method call, runs the advice, and delegates to the real method.

• If the bean implements an interface → Spring uses a JDK dynamic proxy.
• If not → Spring uses CGLIB (subclass proxy).

The repository hierarchy

• Repository<T, ID> — marker, no methods.
• CrudRepository<T, ID> — adds save, findById, delete, count.
• PagingAndSortingRepository<T, ID> — adds Page<T> findAll(Pageable).
• JpaRepository<T, ID> — adds JPA-specific bits like flush(), saveAndFlush(), batch ops.

interface UserRepository extends JpaRepository<User, Long> {

    // SELECT * FROM users WHERE email = ?
    Optional<User> findByEmail(String email);

    // SELECT * FROM users WHERE active = true ORDER BY created_at DESC
    List<User> findByActiveTrueOrderByCreatedAtDesc();

    // SELECT COUNT(*) FROM users WHERE org_id = ?
    long countByOrgId(String orgId);

    // Custom JPQL when name parsing isn't enough
    @Query("select u from User u where u.email like :pattern")
    List<User> searchByEmail(@Param("pattern") String pattern);

    // Native SQL when JPQL isn't enough
    @Query(value = "SELECT * FROM users WHERE created_at > NOW() - INTERVAL '7 days'",
            nativeQuery = true)
    List<User> recentlyCreated();
}

How method names become queries

Spring Data parses your method name at startup using a state machine: findBy + property + (operator) + connector + property. Operators include And, Or, Like, StartingWith, GreaterThan, Between, In, IsNull. If the parser can't resolve a property, the app fails fast at startup — not at runtime.

Pagination & sorting

Pageable page = PageRequest.of(0, 20, Sort.by("createdAt").descending());
Page<User> result = repo.findAll(page);

result.getContent();         // the items
result.getTotalElements();   // total count (extra COUNT query)
result.getTotalPages();      // total pages
result.hasNext();            // more to come?

The mechanics

Spring wraps your bean in an AOP proxy. When you call an @Transactional method, the proxy:

1. Asks the PlatformTransactionManager for a transaction (start a new one or join an existing one based on propagation).
2. Invokes your method.
3. If your method completes normally → commit.
4. If your method throws an unchecked exception (RuntimeException) or Error → rollback.
5. Checked exceptions → commit (unless you set rollbackFor).

Propagation — what to do when a transaction already exists

Isolation — what dirty reads / phantoms / etc. you allow

Common bugs

The setup

@Entity
class Order {
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "customer_id")
    private Customer customer;
    // ...
}

// Then:
List<Order> orders = repo.findAll();      // 1 query
for (Order o : orders) {
    String name = o.getCustomer().getName();   // triggers 1 query per order!
}

Result: 1 + N queries. With 1000 orders, 1001 round-trips to the DB.

Three fixes

@Query("select o from Order o join fetch o.customer")
List<Order> findAllWithCustomer();

@EntityGraph(attributePaths = {"customer", "items"})
List<Order> findAll();

# in application.yml
spring.jpa.properties.hibernate.default_batch_fetch_size: 50

# Now Hibernate loads up to 50 customers in ONE query: WHERE customer_id IN (...)

FetchType — which default to pick

• FetchType.LAZY — load when accessed. Default for @OneToMany / @ManyToMany.
• FetchType.EAGER — load with the parent. Default for @ManyToOne / @OneToOne.

The annotations

@Service
class UserService {

    @Cacheable(value = "users", key = "#id")
    public User findById(String id) {
        return repo.findById(id).orElseThrow();
    }

    @CachePut(value = "users", key = "#user.id")
    public User update(User user) {
        return repo.save(user);   // run AND update cache
    }

    @CacheEvict(value = "users", key = "#id")
    public void delete(String id) { repo.deleteById(id); }

    @CacheEvict(value = "users", allEntries = true)
    public void clearAll() { }
}

And on the application class:

@SpringBootApplication
@EnableCaching
class App { }

# Add to pom.xml for Caffeine (in-memory) or Redis (distributed):
# spring-boot-starter-cache + caffeine, or + spring-boot-starter-data-redis

Cache pitfalls

@SpringBootApplication
@EnableAsync
@EnableScheduling
class App { }

@Service
class EmailService {

    @Async
    public CompletableFuture<Void> sendWelcome(User u) {
        // runs on a different thread; returns immediately to caller
        smtp.send(u.email, "Welcome!");
        return CompletableFuture.completedFuture(null);
    }
}

@Component
class CleanupJob {

    @Scheduled(cron = "0 0 3 * * *")         // every day at 3 AM
    public void deleteOldOrders() { ... }

    @Scheduled(fixedDelay = 10_000)          // 10s after previous run finishes
    public void heartbeat() { ... }

    @Scheduled(fixedRate = 60_000)            // every 60s, regardless of duration
    public void poll() { ... }
}

@Async — what to know

• Methods can return void, CompletableFuture<T>, or ListenableFuture<T>.
• Same self-invocation rule — calling this.someAsyncMethod() from within the same bean runs synchronously.
• By default, uses SimpleAsyncTaskExecutor — creates a new thread per call. Replace it: define a TaskExecutor bean named taskExecutor or a ThreadPoolTaskExecutor bean.

@Scheduled — what to know

• Default thread pool is single-threaded — long-running jobs delay other jobs. Add a ThreadPoolTaskScheduler bean for parallelism.
• Cron uses Spring's 6-field syntax (second minute hour day-of-month month day-of-week) — different from Linux cron's 5 fields.
• In a multi-instance deployment, every instance fires the schedule. For "run only once across the cluster," use ShedLock or quartz.

The big picture

Spring Security is a chain of servlet filters that intercepts every request before it reaches your controller. Each filter has one job: parse a JWT, check a session, authorize a route, etc. The chain ends at FilterSecurityInterceptor, which decides authorize-or-deny.

1. SecurityContextPersistenceFilter — load existing auth from session, store at end.
2. UsernamePasswordAuthenticationFilter — for form login posts.
3. BasicAuthenticationFilter — for HTTP Basic.
4. BearerTokenAuthenticationFilter — for JWTs (OAuth2 resource server).
5. ExceptionTranslationFilter — converts security exceptions into HTTP responses.
6. FilterSecurityInterceptor — the final authorization gate.

Modern config (Spring Security 6+)

@Configuration
@EnableWebSecurity
class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        return http
            .csrf(c -> c.disable())
            .authorizeHttpRequests(a -> a
                .requestMatchers("/api/public/**").permitAll()
                .requestMatchers("/api/admin/**").hasRole("ADMIN")
                .anyRequest().authenticated()
            )
            .oauth2ResourceServer(o -> o.jwt(Customizer.withDefaults()))
            .sessionManagement(s -> s.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
            .build();
    }
}

Authentication vs Authorization

• Authentication — "who are you?" Verifies credentials, produces an Authentication object.
• Authorization — "what are you allowed to do?" Checks the principal's authorities/roles against the resource's requirements.

Method-level security

@EnableMethodSecurity
class SecurityConfig { }

@Service
class OrderService {
    @PreAuthorize("hasRole('ADMIN') or #userId == authentication.principal.id")
    public List<Order> forUser(String userId) { ... }
}

JWT in 60 seconds

A JWT is three Base64-encoded parts joined by dots: header.payload.signature. The header says the algorithm; the payload holds claims (subject, expiry, custom data); the signature proves the token wasn't tampered with.

• Stateless — server doesn't store sessions; the token IS the session.
• Self-contained — every claim the API needs is in the token (user id, roles, expiry).
• Verifiable — server validates signature with a known key (HMAC) or public key (RSA/EC).

The Spring Security 6 setup

# pom.xml: spring-boot-starter-oauth2-resource-server

# application.yml
spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://auth.example.com
          # Spring auto-discovers /.well-known/openid-configuration
          # and pulls the JWKS endpoint to verify signatures

That's it. Spring registers the right filter, validates each incoming JWT, and exposes the principal as Jwt or your custom converter's output.

OAuth2 — the four roles

The grant flows

• Authorization Code (with PKCE) — for SPAs and mobile apps. The modern default.
• Client Credentials — for service-to-service (no user involved).
• Resource Owner Password — deprecated; never use for new apps.
• Implicit — deprecated; use Auth Code + PKCE instead.

Add spring-boot-starter-actuator and you instantly get:

management:
  endpoints:
    web:
      exposure:
        include: "health,info,metrics,prometheus"
  endpoint:
    health:
      show-details: when_authorized
  metrics:
    tags:
      application: ${spring.application.name}
      environment: ${spring.profiles.active}

Custom HealthIndicator

@Component
class PaymentGatewayHealth implements HealthIndicator {

    @Override
    public Health health() {
        if (gateway.ping()) return Health.up().build();
        return Health.down().withDetail("reason", "timeout").build();
    }
}

Liveness vs Readiness (Kubernetes)

• /actuator/health/liveness — "is the JVM alive?" K8s restarts the pod if this fails.
• /actuator/health/readiness — "ready to serve traffic?" K8s removes the pod from load-balancer rotation if this fails.

The pyramid

@WebMvcTest(OrderController.class)
class OrderControllerTest {

    @Autowired MockMvc mvc;
    @MockBean OrderService svc;

    @Test
    void getOrderReturnsJson() throws Exception {
        when(svc.findById("o-1")).thenReturn(new OrderDto("o-1", 499.0));

        mvc.perform(get("/api/v1/orders/o-1"))
           .andExpect(status().isOk())
           .andExpect(jsonPath("$.id").value("o-1"));
    }
}

Testcontainers — the "real" integration test

Don't test against H2 if production runs Postgres — Hibernate's SQL diverges between dialects. Spin up a real Postgres in a container:

@SpringBootTest
@Testcontainers
class OrderIntegrationTest {

    @Container
    static PostgreSQLContainer<?> pg = new PostgreSQLContainer<>("postgres:16");

    @DynamicPropertySource
    static void props(DynamicPropertyRegistry r) {
        r.add("spring.datasource.url", pg::getJdbcUrl);
        r.add("spring.datasource.username", pg::getUsername);
        r.add("spring.datasource.password", pg::getPassword);
    }
    // ... tests
}

The building blocks

OpenFeign — calling services without writing HTTP plumbing

@FeignClient(name = "inventory-service")
interface InventoryClient {
    @GetMapping("/items/{sku}")
    Item getItem(@PathVariable String sku);
}

// Then just:
@Service
class CheckoutService {
    private final InventoryClient inventory;
    // ...
    inventory.getItem("SKU-42");   // Spring generates the HTTP call
}

Spring Cloud Gateway routes

spring:
  cloud:
    gateway:
      routes:
        - id: orders
          uri: lb://orders-service
          predicates:
            - Path=/api/v1/orders/**
          filters:
            - StripPrefix=2
            - AddRequestHeader=X-Origin, gateway

The four patterns

• Retry — try again on transient failure (with backoff).
• Circuit Breaker — stop calling a flaky dependency; fail fast for a cooldown window.
• Bulkhead — limit concurrent calls so one slow dependency can't exhaust the whole thread pool.
• Rate Limiter — cap calls per time window.

@Service
class PaymentService {

    @CircuitBreaker(name = "razorpay", fallbackMethod = "fallback")
    @Retry(name = "razorpay")
    public PaymentResult charge(Order o) {
        return client.post("/charge", o);
    }

    public PaymentResult fallback(Order o, Throwable t) {
        return PaymentResult.queued(o.id);   // degrade gracefully
    }
}

resilience4j:
  circuitbreaker:
    instances:
      razorpay:
        failure-rate-threshold: 50     # open if >50% of last N calls fail
        sliding-window-size: 10
        wait-duration-in-open-state: 30s  # cooldown before half-open
  retry:
    instances:
      razorpay:
        max-attempts: 3
        wait-duration: 200ms
        exponential-backoff-multiplier: 2

Circuit breaker states

• CLOSED — normal; calls go through.
• OPEN — failure threshold breached; calls fail-fast without hitting the dependency.
• HALF_OPEN — after wait duration, allow a few probe calls. If they succeed → CLOSED. If they fail → back to OPEN.

The big shifts in Spring Boot 3

• Java 17 minimum — finally drops Java 8.
• jakarta.* instead of javax.* — the namespace move that broke half of the Java ecosystem in 2022.
• Spring Framework 6 as the base.
• First-class GraalVM native image support via Spring AOT.
• Observability via Micrometer (replaces Sleuth) — tracing + metrics in one library.
• HTTP interface clients — declarative HTTP without OpenFeign.

Why native images matter

GraalVM ahead-of-time compiles your Spring Boot app to a native executable. Trade-offs:

Use native for serverless (cold start matters), CLI tools, low-memory containers. Stay on JVM for long-running, high-throughput services.

These appear when interviewers want to separate "I followed a tutorial" from "I shipped Spring." Memorize a few; they pay back massively.

1. Self-invocation kills annotations

Calling this.foo() from another method in the same bean bypasses the AOP proxy. @Transactional, @Cacheable, @Async, custom aspects — all silently no-op. Fix: inject self-reference, split into two beans, or use AspectJ load-time weaving.

2. @Value on a static field doesn't work

Spring injects values via setters/fields on instances. Statics are class-level, set before any instance exists. Use a non-static field, or @PostConstruct to copy a non-static into a static.

3. Bean creation order is not source order

Spring resolves the dependency graph and instantiates in topological order. Don't assume "A is declared above B → A is created first." If you need explicit ordering, use @DependsOn.

4. Circular dependencies

A → needs B → needs A. Spring used to allow this with field/setter injection by partial wiring. Spring Boot 2.6+ fails on startup by default. Fix: refactor (the cycle is a design smell), use @Lazy on one side, or set spring.main.allow-circular-references=true (don't).

5. List<MyBean> auto-injection

Spring will inject all beans of type MyBean as a list. Useful for plugin patterns ("apply every OrderValidator"). Combine with @Order for deterministic ordering.

@Service
class OrderProcessor {
    private final List<OrderValidator> validators;   // all impls injected

    public void validate(Order o) {
        validators.forEach(v -> v.validate(o));
    }
}

6. @RequestParam required-true is the default

Forgot to mark it optional? Missing param = 400 Bad Request. Use @RequestParam(required=false) or a default: @RequestParam(defaultValue="0").

7. @Transactional on JPA: changes outside the transaction are NOT flushed

Setting an entity field outside a @Transactional method (or after commit) doesn't persist. The entity becomes "detached." A common WTF moment.

8. save() doesn't always trigger an INSERT

Spring Data's save() returns the merged entity. For a NEW entity (id=null), Hibernate INSERTs. For an EXISTING one, it's a SELECT-then-UPDATE — and if no fields changed, no UPDATE. Don't assume one DB hit per save().

9. @MockBean changes the context

Each unique mock combination = a different ApplicationContext = re-bootstrap on every test class. Slow test suites often trace to this. Standardize @MockBean usage; consider @SpyBean sparingly.

10. @SpringBootApplication position matters

Component scan starts from the package of the @SpringBootApplication class. Put it in com.example.app and it scans com.example.app and below. A bean in com.example.other won't be picked up. Always place the main class at the root package.

11. application.properties and application.yml together

You can have both. Spring loads both, but application.properties takes precedence over application.yml. If a property exists in both, properties wins. Pick one and stick with it.

12. @Bean vs @Component

@Component is on the class — Spring instantiates it via constructor. @Bean is on a method inside @Configuration — you control how the bean is built. Use @Bean when you need to wire third-party classes (you can't put @Component on someone else's library class) or when construction has logic.

13. @RestController + entity return = potential problem

Returning a JPA entity directly from a controller serializes lazy associations (LazyInitializationException) or pulls the world (eager). Return DTOs, not entities. The DTO mapping is one boilerplate step that pays back tenfold.

14. JSON deserialization without default constructor

Jackson needs either a no-arg constructor + setters, or constructor with @JsonCreator. Java records work out of the box (Jackson 2.12+).

15. @RequestBody with a String parameter

Trips up some devs: with content-type application/json, Spring tries to parse the body as a JSON-encoded String. Use consumes = "text/plain" or accept a byte[]/InputStream for raw bodies.

16. Logging defaults — Logback, not Log4j

Spring Boot ships Logback as the default. Bringing in Log4j 2 means excluding spring-boot-starter-logging first, else both load and log lines double.

17. WebClient vs RestTemplate

RestTemplate is in maintenance mode (no new features) but not deprecated. WebClient (from WebFlux) is recommended for new code — it's reactive but works synchronously too. In Spring 6.1+, RestClient is the new sync-friendly alternative — WebClient-style fluent API without the reactive types.

18. Property placeholder fallbacks

${db.url:jdbc:h2:mem:default} — colon = default if missing. Saves countless "missing property" startup failures in dev.

19. spring.jpa.open-in-view defaults to TRUE

This is the controversial one. It keeps the Hibernate session open through the entire request — so lazy associations work in views/controllers. But it also: hides N+1 (now they happen during rendering), holds DB connections longer, and masks design issues. Most teams turn it off (false) and load eagerly via DTOs / EntityGraphs.

20. @Configuration vs @Configuration(proxyBeanMethods = false)

By default, @Configuration classes are CGLIB-proxied so calls between @Bean methods return the singleton, not a new instance. Setting proxyBeanMethods = false skips the proxy → faster startup, smaller native images, but you lose that singleton-via-method-call magic. Spring Boot 2.2+ uses this in its own auto-configurations.