Introduction to Spring Boot

🍃 Spring Boot · Getting Started · 6 min read

Spring Boot is an opinionated framework built on top of the Spring Framework that makes it radically easier to create stand-alone, production-grade Spring applications. Its motto: "just run" — minimal configuration, an embedded server, and sensible defaults.

What It Gives You

Auto-configuration — wires beans based on the classpath, so you write almost no XML/config.
Starters — curated dependency bundles (spring-boot-starter-web).
Embedded server — Tomcat/Jetty/Undertow built in; run a fat JAR with java -jar.
Actuator — production endpoints (health, metrics) out of the box.
No code generation, no XML — convention over configuration.

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}
@RestController
class HelloController {
    @GetMapping("/hello")
    String hello() { return "Hello, Spring Boot!"; }
}

💡 @SpringBootApplication bundles three annotations: @SpringBootConfiguration + @EnableAutoConfiguration + @ComponentScan. That one line is the whole "magic."

Spring Framework vs Spring Boot

🍃 Spring Boot · Getting Started · 5 min read

Spring Framework is the core (IoC, DI, MVC, data). Spring Boot is a layer on top that removes the boilerplate of configuring it.

	Spring Framework	Spring Boot
Configuration	Manual (XML/Java config)	Auto-configured
Server	External (deploy WAR)	Embedded (fat JAR)
Dependencies	Pick each manually	Starters bundle them
Setup time	High	Minutes
Production features	Add yourself	Actuator built-in

💡 Spring Boot doesn't replace Spring — it uses it. Interview line: "Spring Boot is opinionated auto-configuration + starters + embedded server on top of the Spring Framework."

Spring Boot Architecture

🍃 Spring Boot · Getting Started · 6 min read

A typical Spring Boot app is layered, with requests flowing through clearly-separated tiers.

Controller layer — HTTP endpoints, request/response mapping.
Service layer — business logic, transactions.
Repository layer — data access (Spring Data JPA).
Model/Entity — domain objects.

💡 This separation of concerns keeps code testable: mock the repository to unit-test the service, mock the service to test the controller.

Spring Boot Starters

🍃 Spring Boot · Getting Started · 5 min read

Starters are curated dependency descriptors — add one and you get a whole consistent set of compatible libraries, version-managed for you.

Starter	Brings in
`spring-boot-starter-web`	Spring MVC, Jackson, embedded Tomcat
`spring-boot-starter-data-jpa`	Hibernate, Spring Data, JDBC
`spring-boot-starter-security`	Spring Security
`spring-boot-starter-actuator`	Production endpoints
`spring-boot-starter-test`	JUnit 5, Mockito, AssertJ

💡 Versions come from the spring-boot-starter-parent (or BOM), so you never specify versions for starter-managed libs — eliminating dependency conflicts.

Spring Boot Auto Configuration

🍃 Spring Boot · Getting Started · ★ Interview Topic · 9 min read

Auto-configuration is Spring Boot's defining feature: it automatically configures beans based on what's on the classpath, what beans already exist, and your properties — so you get a working app with almost zero manual config.

How It Works — Visual

The Mechanism

@EnableAutoConfiguration (inside @SpringBootApplication) triggers it.
Spring reads auto-config classes listed in META-INF/spring/...AutoConfiguration.imports.
Each is gated by @Conditional annotations:

Condition	Applies config if…
`@ConditionalOnClass`	A class is on the classpath (e.g. `DataSource`)
`@ConditionalOnMissingBean`	You haven't defined that bean yourself
`@ConditionalOnProperty`	A property is set

# see what got auto-configured and why
java -jar app.jar --debug      # prints the "Conditions Evaluation Report"

💡 The key insight: @ConditionalOnMissingBean means your beans always win — auto-config only fills gaps. Add the JPA starter → a DataSource auto-configures; define your own DataSource → Boot backs off. Disable specific ones with @SpringBootApplication(exclude=...).

Spring Boot Project Structure

🍃 Spring Boot · Getting Started · 4 min read

A conventional package-by-layer (or package-by-feature) structure keeps Spring Boot apps maintainable.

src/main/java/com/example/app/
├── Application.java          # @SpringBootApplication (root package!)
├── controller/              # @RestController
├── service/                 # @Service business logic
├── repository/              # @Repository data access
├── entity/                  # @Entity JPA models
├── dto/                     # request/response objects
└── config/                  # @Configuration classes
src/main/resources/
├── application.yml
└── static/ , templates/

💡 Put Application.java in the root package — component scanning starts there and covers all sub-packages automatically. Misplacing it (too deep) is a common "my beans aren't found" bug.

Spring Boot Annotations

🍃 Spring Boot · Getting Started · 5 min read

A quick reference to the annotations you'll use constantly.

Annotation	Purpose
`@SpringBootApplication`	Main entry (config + auto-config + scan)
`@RestController` / `@Controller`	Web endpoints
`@Service` / `@Repository` / `@Component`	Beans by role
`@Autowired`	Inject a dependency
`@Configuration` / `@Bean`	Java-based bean definitions
`@Value` / `@ConfigurationProperties`	Bind properties
`@GetMapping` / `@PostMapping` …	Route HTTP methods
`@Transactional`	Declarative transactions

💡 Most Spring annotations are meta-annotations composed of others (e.g. @RestController = @Controller + @ResponseBody). Understanding the composition demystifies them.

Dependency Injection (DI) & IoC

🍃 Spring Boot · Core & IoC · ★ Interview Topic · 9 min read

Inversion of Control (IoC) means the framework — not your code — creates and wires objects. Dependency Injection is how IoC is implemented: Spring injects a class's dependencies instead of the class constructing them itself. The result: loose coupling and easy testing.

Without vs With DI — Visual

Constructor Injection (Recommended)

@Service
public class NotificationService {
    private final EmailService email;
    public NotificationService(EmailService email) {   // injected by Spring
        this.email = email;
    }
}

Three Injection Types

Type	Notes
Constructor (best)	Immutable, testable, fails fast, allows `final`
Setter	For optional dependencies
Field (`@Autowired`)	Concise but hard to test, no `final` — avoid

💡 Prefer constructor injection: dependencies are explicit, the object is always valid once built, and you can test it with plain new + mocks. Since Spring 4.3, a single constructor needs no @Autowired.

Inversion of Control (IoC)

🍃 Spring Boot · Core & IoC · 4 min read

IoC is the principle that control over object creation and lifecycle is inverted — handed from your code to a container. The Spring IoC Container (ApplicationContext) creates, configures, wires, and manages beans.

BeanFactory — basic container.
ApplicationContext — full-featured (events, i18n, AOP); what you actually use.

💡 "Don't call us, we'll call you" (the Hollywood Principle). DI is the most common way to achieve IoC. See Dependency Injection for the practical detail.

Spring Beans

🍃 Spring Boot · Core & IoC · 4 min read

A bean is simply an object that the Spring IoC container creates, manages, and wires. You declare beans by annotating classes (@Component & friends) or with @Bean methods in a @Configuration class.

@Configuration
class AppConfig {
    @Bean
    RestTemplate restTemplate() {       // method return value = a managed bean
        return new RestTemplate();
    }
}

💡 Two ways to register beans: stereotype annotations (auto-detected by component scanning) or explicit @Bean methods (for third-party classes you can't annotate).

Bean Lifecycle

🍃 Spring Boot · Core & IoC · ★ Interview Topic · 8 min read

The container manages a bean from creation to destruction through well-defined phases — with hooks you can tap into for initialization and cleanup.

Lifecycle Phases — Visual

@Component
class CacheManager {
    @PostConstruct void init()    { /* warm cache after deps injected */ }
    @PreDestroy   void cleanup()  { /* flush/close on shutdown */ }
}

Hooks (in order)

Constructor → dependency injection → @PostConstruct → InitializingBean.afterPropertiesSet() → custom initMethod.
On shutdown: @PreDestroy → DisposableBean.destroy() → custom destroyMethod.
BeanPostProcessor can intercept all beans before/after init (how AOP proxies are applied).

💡 Use @PostConstruct for setup needing injected dependencies (the constructor runs before injection). Prototype-scoped beans get no destruction callback — the container doesn't manage their full lifecycle.

Bean Scopes

🍃 Spring Boot · Core & IoC · ★ Interview Topic · 8 min read

A bean's scope defines its lifecycle and how many instances exist. The default — singleton — means one shared instance per container.

Scope	Instances	Use
`singleton` (default)	One per container	Stateless services
`prototype`	New on each injection/lookup	Stateful, short-lived
`request`	One per HTTP request	Web
`session`	One per HTTP session	Web
`application`	One per ServletContext	Web

@Service
@Scope("prototype")
class ReportBuilder { ... }     // fresh instance every time

⚠️ Singletons must be stateless (shared across all threads) — storing mutable per-request state in a singleton is a classic concurrency bug. Injecting a prototype into a singleton "freezes" one instance; use ObjectProvider or scoped proxies to get fresh ones.

Component Scanning

🍃 Spring Boot · Core & IoC · 4 min read

Component scanning is how Spring discovers your beans — it scans packages for classes annotated with @Component (and its specializations) and registers them automatically.

@SpringBootApplication        // includes @ComponentScan on its package
public class App { ... }

// scan additional packages
@ComponentScan(basePackages = {"com.example.app", "com.shared.lib"})

💡 By default scanning starts at the package of your @SpringBootApplication class and includes all sub-packages — which is why the main class belongs in the root package. Beans outside that tree won't be found unless you add @ComponentScan.

@Component

🍃 Spring Boot · Stereotypes · 3 min read

@Component is the generic stereotype marking a class as a Spring-managed bean, eligible for component scanning. @Service, @Repository, and @Controller are specializations of it.

@Component
public class EmailValidator {
    public boolean isValid(String email) { ... }
}

💡 Use @Component for general helpers that don't fit the service/repository/controller roles. The specialized stereotypes add semantics (and behaviour, like exception translation for @Repository).

@Service

🍃 Spring Boot · Stereotypes · 3 min read

@Service marks a class holding business logic — the service layer. Functionally identical to @Component, but it documents intent and is the conventional place for @Transactional logic.

@Service
public class OrderService {
    private final OrderRepository repo;
    public OrderService(OrderRepository repo) { this.repo = repo; }
    public Order place(OrderRequest req) { /* business rules */ }
}

💡 Keep controllers thin and push logic into services. Services orchestrate repositories and own transaction boundaries.

@Repository

🍃 Spring Boot · Stereotypes · 3 min read

@Repository marks the data-access layer. Beyond being a bean, it enables exception translation — converting vendor-specific persistence exceptions into Spring's consistent DataAccessException hierarchy.

@Repository
public interface UserRepository extends JpaRepository<User, Long> { }

💡 With Spring Data JPA, repository interfaces are detected automatically — the @Repository annotation is optional there but still good for clarity in custom DAO classes.

@Controller

🍃 Spring Boot · Stereotypes · 3 min read

@Controller marks a web controller in Spring MVC. By default its methods return view names (rendered by a template engine like Thymeleaf), not response bodies.

@Controller
public class PageController {
    @GetMapping("/home")
    public String home(Model model) {
        model.addAttribute("user", user);
        return "home";          // resolves to home.html template
    }
}

💡 Use @Controller for server-rendered HTML (this very site uses it with Thymeleaf). For JSON REST APIs, use @RestController (next).

@RestController

🍃 Spring Boot · Stereotypes · 3 min read

@RestController = @Controller + @ResponseBody. Every method returns data (serialized to JSON by Jackson) directly as the HTTP response body — the standard for REST APIs.

@RestController
@RequestMapping("/api/users")
public class UserController {
    @GetMapping("/{id}")
    public User get(@PathVariable Long id) {
        return userService.findById(id);   // auto-serialized to JSON
    }
}

💡 The difference in one line: @Controller returns view names; @RestController returns serialized objects (JSON/XML). No need to annotate each method with @ResponseBody.

application.properties

🍃 Spring Boot · Configuration · 4 min read

The default config file (in src/main/resources). Key-value pairs configure the app, server, datasource, logging, and any custom property.

# application.properties
server.port=8081
spring.datasource.url=jdbc:postgresql://localhost:5432/app
spring.jpa.hibernate.ddl-auto=update
logging.level.com.example=DEBUG
app.feature.new-checkout=true        # custom property

💡 Spring Boot reads hundreds of "common application properties" automatically. Reference a value with ${...} and inject with @Value or @ConfigurationProperties.

application.yml

🍃 Spring Boot · Configuration · 4 min read

YAML is an alternative to .properties — hierarchical, less repetitive, and easier to read for nested config.

# application.yml
server:
  port: 8081
spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/app
  jpa:
    hibernate:
      ddl-auto: update
app:
  feature:
    new-checkout: true

⚠️ YAML is indentation-sensitive (spaces, never tabs). Don't mix .properties and .yml for the same keys — pick one. YAML also supports multi-document files (---) for per-profile config.

Profiles (@Profile)

🍃 Spring Boot · Configuration · 5 min read

Profiles let you define environment-specific configuration and beans (dev, staging, prod) and switch between them at runtime.

# profile-specific files
application.yml            # shared defaults
application-dev.yml        # dev overrides
application-prod.yml       # prod overrides

# activate a profile
java -jar app.jar --spring.profiles.active=prod
# or env var: SPRING_PROFILES_ACTIVE=prod

@Bean @Profile("dev")
DataSource h2DataSource() { ... }   // only created in dev

💡 Profiles keep one artifact deployable to every environment — only the active profile changes. Combine with externalized config for 12-factor compliance.

Configuration Properties

🍃 Spring Boot · Configuration · 5 min read

@ConfigurationProperties binds a group of related properties to a strongly-typed POJO — cleaner and safer than scattering @Value everywhere.

@Component
@ConfigurationProperties(prefix = "app.mail")
public class MailProperties {
    private String host;
    private int port;
    private String from;
    // getters/setters — bound from app.mail.host, app.mail.port, ...
}

	@Value	@ConfigurationProperties
Binds	One property	A group (prefix)
Type-safe	Limited	Yes (+ validation)
Relaxed binding	No	Yes (kebab/camel/env)

💡 Prefer @ConfigurationProperties for grouped config — it supports validation (@Validated), relaxed binding (app.mail.from = APP_MAIL_FROM), and IDE metadata.

Externalized Configuration

🍃 Spring Boot · Configuration · 5 min read

Spring Boot lets you externalize config so the same code runs in any environment — pulling values from many sources in a defined precedence order.

Precedence (high → low)

Command-line args (--server.port=9000)
OS environment variables (SERVER_PORT)
External application.yml (outside the jar)
Profile-specific files
Packaged application.yml

💡 This precedence is the foundation of 12-factor config: bake defaults into the jar, override per environment via env vars / Docker / Kubernetes ConfigMaps & Secrets — no rebuild needed. For distributed systems, see Config Server.

REST API Development & Design

🍃 Spring Boot · REST API · ★ Interview Topic · 10 min read

REST (Representational State Transfer) is an architectural style for web APIs: resources identified by URLs, manipulated with HTTP verbs, communicating statelessly. Spring Boot makes building them trivial.

Resource + Verb Mapping — Visual

A Complete Controller

@RestController
@RequestMapping("/api/users")
public class UserController {
    private final UserService service;
    public UserController(UserService s) { this.service = s; }

    @GetMapping            List<User> all() { return service.findAll(); }
    @GetMapping("/{id}")   User one(@PathVariable Long id) { return service.find(id); }
    @PostMapping
    @ResponseStatus(HttpStatus.CREATED)
    User create(@Valid @RequestBody UserRequest r) { return service.create(r); }
    @PutMapping("/{id}")   User update(@PathVariable Long id, @RequestBody UserRequest r) { ... }
    @DeleteMapping("/{id}")
    @ResponseStatus(HttpStatus.NO_CONTENT)
    void delete(@PathVariable Long id) { service.delete(id); }
}

REST Design Best Practices

Nouns, not verbs in URLs (/users, not /getUsers); plural resources.
Correct status codes (200, 201, 204, 400, 404, 409, 500).
Stateless — no server session; auth via token per request.
Use DTOs (not entities) at the boundary; validate input; version the API.
Consistent error responses, pagination for collections, HATEOAS optional.

💡 Senior-level answer: map CRUD to HTTP verbs + correct status codes, separate DTOs from entities, keep it stateless, validate at the edge, and design idempotent PUT/DELETE. These principles come up in almost every architect interview.

Request Mapping

🍃 Spring Boot · REST API · 4 min read

@RequestMapping (and its shortcuts) map HTTP requests to handler methods by path, method, headers, and content type.

@RequestMapping(value="/api", method=RequestMethod.GET)   // generic
@GetMapping("/users")        // shortcut for GET
@PostMapping("/users")       // POST
@PutMapping  @DeleteMapping  @PatchMapping
@GetMapping(value="/x", produces="application/json", consumes="application/json")

💡 Prefer the method-specific shortcuts (@GetMapping etc.) over generic @RequestMapping — clearer and less error-prone. Class-level @RequestMapping sets a base path for all methods.

Path Variables

🍃 Spring Boot · REST API · 3 min read

@PathVariable binds a URI template segment to a method parameter — for identifying a specific resource.

@GetMapping("/users/{id}/orders/{orderId}")
Order get(@PathVariable Long id,
          @PathVariable("orderId") Long oid) { ... }

💡 Use path variables for resource identity (/users/42). For optional filters/search, use query parameters instead (next topic).

Request Parameters

🍃 Spring Boot · REST API · 3 min read

@RequestParam binds query-string (or form) parameters — for filtering, sorting, and pagination.

// GET /users?status=active&page=0&size=20
@GetMapping("/users")
List<User> search(
    @RequestParam(defaultValue="all") String status,
    @RequestParam(required=false) String name,
    @RequestParam(defaultValue="0") int page) { ... }

💡 Use defaultValue / required=false for optional params. Path variable = identity; request param = options/filters.

Request Body

🍃 Spring Boot · REST API · 3 min read

@RequestBody deserializes the HTTP request body (JSON) into a Java object via Jackson — used for POST/PUT payloads.

@PostMapping("/users")
User create(@Valid @RequestBody UserRequest request) {
    return service.create(request);   // JSON → UserRequest automatically
}

💡 Combine @RequestBody with @Valid to validate the payload before your method runs. Accept a DTO, not your entity, to control the API contract.

Response Entity

🍃 Spring Boot · REST API · 4 min read

ResponseEntity<T> gives full control over the HTTP response — status code, headers, and body — instead of just returning the body.

@GetMapping("/users/{id}")
ResponseEntity<User> get(@PathVariable Long id) {
    return service.find(id)
        .map(ResponseEntity::ok)                       // 200 + body
        .orElse(ResponseEntity.notFound().build());    // 404
}
return ResponseEntity.created(location).body(saved);   // 201 + Location header

💡 Return the plain object for simple 200 cases; use ResponseEntity when you need custom status, headers, or conditional responses (404 vs 200).

API Versioning

🍃 Spring Boot · REST API · 4 min read

Versioning lets you evolve an API without breaking existing clients. Several strategies:

Strategy	Example
URI path	`/api/v1/users` (most common, clear)
Query param	`/api/users?version=1`
Header	`X-API-Version: 1`
Content negotiation	`Accept: application/vnd.app.v1+json`

💡 URI versioning (/v1/) is the most popular for its simplicity and cache-friendliness. Whatever you pick, keep old versions running during a deprecation window and communicate the timeline.

Exception Handling

🍃 Spring Boot · Validation & Exceptions · ★ Interview Topic · 9 min read

Robust APIs translate exceptions into meaningful, consistent HTTP responses. Spring offers per-controller (@ExceptionHandler) and global (@RestControllerAdvice) handling.

Flow — Visual

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(ResourceNotFoundException.class)
    @ResponseStatus(HttpStatus.NOT_FOUND)
    ApiError notFound(ResourceNotFoundException ex) {
        return new ApiError(404, ex.getMessage());
    }

    @ExceptionHandler(MethodArgumentNotValidException.class)   // validation errors
    @ResponseStatus(HttpStatus.BAD_REQUEST)
    Map<String,String> invalid(MethodArgumentNotValidException ex) {
        var errors = new HashMap<String,String>();
        ex.getBindingResult().getFieldErrors()
          .forEach(e -> errors.put(e.getField(), e.getDefaultMessage()));
        return errors;
    }
}

💡 Use @RestControllerAdvice for one centralized place that converts every exception into a consistent error shape. Map domain exceptions to proper status codes (404, 409, 400) — never leak stack traces to clients.

Global Exception Handling

🍃 Spring Boot · Validation & Exceptions · 4 min read

@RestControllerAdvice (= @ControllerAdvice + @ResponseBody) applies @ExceptionHandler methods across all controllers — DRY, consistent error handling.

@RestControllerAdvice
class ApiExceptionHandler extends ResponseEntityExceptionHandler {
    @ExceptionHandler(Exception.class)
    ResponseEntity<ApiError> handleAll(Exception ex) {
        return ResponseEntity.status(500).body(new ApiError(500, "Internal error"));
    }
}

💡 Order handlers from most-specific to most-generic. Extend ResponseEntityExceptionHandler to customize Spring's built-in exceptions (validation, 404, etc.). Consider RFC 7807 ProblemDetail (Spring 6) for standardized error bodies.

Validation (@Valid)

🍃 Spring Boot · Validation & Exceptions · ★ Interview Topic · 8 min read

Bean Validation (Jakarta Validation / Hibernate Validator) declaratively validates request data using annotations. @Valid triggers it; failures become 400 Bad Request.

Constraint Annotations

public class UserRequest {
    @NotBlank(message = "name is required")
    private String name;
    @Email @NotNull
    private String email;
    @Min(18) @Max(120)
    private int age;
    @Size(min = 8, message = "password too short")
    private String password;
    @Pattern(regexp = "\\d{10}")
    private String phone;
}

@PostMapping("/users")
User create(@Valid @RequestBody UserRequest req) { ... }   // validates before body runs

Annotation	Checks
`@NotNull / @NotBlank / @NotEmpty`	Presence
`@Size / @Min / @Max`	Bounds
`@Email / @Pattern`	Format
`@Past / @Future`	Dates

💡 @Valid on a @RequestBody throws MethodArgumentNotValidException on failure — catch it in your @RestControllerAdvice to return field-level error messages. Use @Validated at class level for method-parameter validation and validation groups.

Custom Validation

🍃 Spring Boot · Validation & Exceptions · 4 min read

When built-in constraints aren't enough, create a custom annotation backed by a ConstraintValidator.

@Target(FIELD) @Retention(RUNTIME)
@Constraint(validatedBy = StrongPasswordValidator.class)
public @interface StrongPassword { String message() default "weak password"; ... }

public class StrongPasswordValidator
        implements ConstraintValidator<StrongPassword, String> {
    public boolean isValid(String value, ConstraintValidatorContext ctx) {
        return value != null && value.matches("^(?=.*[A-Z])(?=.*\\d).{8,}$");
    }
}
// usage:  @StrongPassword private String password;

💡 Custom validators keep validation declarative and reusable. For cross-field rules (e.g. password == confirmPassword), put the constraint at the class level.

Spring Data JPA

🍃 Spring Boot · Data & JPA · ★ Interview Topic · 10 min read

Spring Data JPA eliminates boilerplate data-access code: you declare a repository interface and Spring generates the implementation at runtime — including queries derived from method names.

The Layers — Visual

Derived Query Methods

public interface UserRepository extends JpaRepository<User, Long> {
    List<User> findByLastName(String lastName);             // auto-implemented
    Optional<User> findByEmail(String email);
    List<User> findByAgeGreaterThanOrderByNameAsc(int age);
    boolean existsByEmail(String email);
    long countByStatus(Status status);
    List<User> findByStatusAndAgeBetween(Status s, int lo, int hi);
}

Spring parses the method name (findBy + properties + keywords like GreaterThan, Between, OrderBy) and writes the query for you.

💡 You get full CRUD + paging/sorting for free by extending JpaRepository, plus name-derived queries, and @Query for anything complex. Interview gold: "I extend JpaRepository and let Spring generate queries from method names; complex ones use @Query (JPQL or native)."

Hibernate

🍃 Spring Boot · Data & JPA · 4 min read

Hibernate is the default JPA implementation (ORM) in Spring Boot — it maps Java objects to database tables and generates SQL, so you work with objects, not rows.

JPA is the specification (interfaces/annotations); Hibernate is the implementation.
Manages the persistence context (first-level cache) and entity state (transient/managed/detached).
Dirty checking — auto-updates changed managed entities at flush time.

💡 JPA : Hibernate :: the API : the engine. Spring Data JPA sits on top of JPA, which Hibernate implements. spring.jpa.hibernate.ddl-auto controls schema generation (use validate/none in prod, never create).

Entity Mapping

🍃 Spring Boot · Data & JPA · 5 min read

An @Entity class maps to a database table; its fields map to columns via annotations.

@Entity
@Table(name = "users")
public class User {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    @Column(nullable = false, unique = true, length = 120)
    private String email;
    @Enumerated(EnumType.STRING)
    private Status status;
    @CreationTimestamp
    private Instant createdAt;
    @Transient
    private int computed;        // not persisted
}

💡 Every entity needs a no-arg constructor and an @Id. Store enums as STRING (not ORDINAL — reordering breaks data). Use wrapper types (Long) for ids so null = "not yet persisted."

Relationships (OneToOne, OneToMany, ManyToMany)

🍃 Spring Boot · Data & JPA · 6 min read

JPA maps table relationships to object references.

@Entity class Order {
    @ManyToOne(fetch = FetchType.LAZY)         // many orders → one user
    @JoinColumn(name = "user_id")
    private User user;

    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<OrderItem> items;             // one order → many items
}
@Entity class Student {
    @ManyToMany
    @JoinTable(name="student_course", ...)     // join table
    private Set<Course> courses;
}

Type	Owning side / default fetch
@OneToOne	FK side / EAGER
@ManyToOne	FK side / EAGER
@OneToMany	`mappedBy` (inverse) / LAZY
@ManyToMany	Join table / LAZY

⚠️ Make @ManyToOne/@OneToOne LAZY explicitly (default EAGER causes surprise queries). Use mappedBy on the inverse side to avoid duplicate FK columns. Watch for the N+1 query problem (see Lazy Loading).

CRUD Repository

🍃 Spring Boot · Data & JPA · 3 min read

CrudRepository<T, ID> provides the basic create-read-update-delete operations for an entity.

interface ProductRepo extends CrudRepository<Product, Long> {}
// inherited methods:
save(entity); saveAll(list);
findById(id); findAll(); existsById(id); count();
deleteById(id); delete(entity);

💡 CrudRepository is the base; JpaRepository extends it with paging, sorting, batch ops, and flush. Most apps extend JpaRepository directly.

JpaRepository

🍃 Spring Boot · Data & JPA · 3 min read

JpaRepository<T, ID> is the richest standard repository — extends PagingAndSortingRepository + CrudRepository and adds JPA-specific methods.

interface UserRepo extends JpaRepository<User, Long> {}
// adds on top of CRUD:
findAll(Sort.by("name"));
findAll(PageRequest.of(0, 20));
saveAndFlush(entity);
deleteAllInBatch();
getReferenceById(id);     // lazy proxy

💡 The hierarchy: Repository → CrudRepository → PagingAndSortingRepository → JpaRepository. Default to JpaRepository unless you want to deliberately restrict the API.

Paging and Sorting

🍃 Spring Boot · Data & JPA · 4 min read

For large datasets, return data in pages with Pageable / Page instead of loading everything.

Page<User> findByStatus(Status status, Pageable pageable);

// controller
@GetMapping("/users")
Page<User> list(@RequestParam int page, @RequestParam int size) {
    return repo.findByStatus(ACTIVE, PageRequest.of(page, size, Sort.by("name")));
}
// Page gives: content, totalElements, totalPages, hasNext()

💡 Spring MVC can resolve Pageable directly from request params (?page=0&size=20&sort=name,desc). Use Slice when you only need "is there a next page" (avoids the count query).

Custom Queries

🍃 Spring Boot · Data & JPA · 4 min read

When derived method names get unwieldy, write the query explicitly with @Query.

@Query("SELECT u FROM User u WHERE u.email = :email")
Optional<User> findByEmail(@Param("email") String email);

@Modifying @Transactional
@Query("UPDATE User u SET u.status = :s WHERE u.lastLogin < :date")
int deactivateStale(@Param("s") Status s, @Param("date") Instant date);

@Query(value = "SELECT * FROM users WHERE ...", nativeQuery = true)   // native SQL
List<User> search(...);

💡 @Query defaults to JPQL; add nativeQuery=true for raw SQL. Use @Modifying for UPDATE/DELETE. See JPQL and Native Queries for details.

JPQL

🍃 Spring Boot · Data & JPA · 4 min read

JPQL (Java Persistence Query Language) is an object-oriented query language — it queries entities and their fields, not tables and columns. Portable across databases.

@Query("SELECT u FROM User u WHERE u.age > :age ORDER BY u.name")
List<User> olderThan(@Param("age") int age);

@Query("SELECT new com.app.dto.UserSummary(u.id, u.name) FROM User u")  // projection
List<UserSummary> summaries();

@Query("SELECT o FROM Order o JOIN FETCH o.items WHERE o.id = :id")      // avoid N+1
Order withItems(@Param("id") Long id);

💡 JPQL uses entity names and fields (User, u.name), not table/column names. JOIN FETCH eagerly loads associations in one query — the standard fix for the N+1 problem.

Native Queries

🍃 Spring Boot · Data & JPA · 4 min read

Native queries run raw SQL — for database-specific features, complex queries, or performance tuning that JPQL can't express.

@Query(value = """
    SELECT * FROM users u
    WHERE u.created_at > :since
    AND u.id IN (SELECT user_id FROM orders GROUP BY user_id HAVING COUNT(*) > 5)
    """, nativeQuery = true)
List<User> powerUsers(@Param("since") Instant since);

⚠️ Native SQL ties you to a specific database and bypasses JPA's caching/dirty-checking. Use it only when JPQL falls short. Always parameterize (:param) — never concatenate input (SQL injection).

Transaction Management

🍃 Spring Boot · Data & JPA · ★ Interview Topic · 10 min read

A transaction groups operations into an all-or-nothing (ACID) unit. Spring's @Transactional makes this declarative — begin, commit, and rollback are handled around your method via an AOP proxy.

How the Proxy Works — Visual

@Service
public class TransferService {
    @Transactional
    public void transfer(Long from, Long to, BigDecimal amt) {
        accounts.debit(from, amt);
        accounts.credit(to, amt);     // if this throws → both roll back
    }
}

Key Rules & Gotchas

By default rolls back on unchecked exceptions (RuntimeException/Error), not checked — override with rollbackFor.
Works via a proxy → self-invocation doesn't work (calling a @Transactional method from within the same class bypasses the proxy).
Put @Transactional on the service layer, not controllers/repositories.
Use readOnly = true for queries (optimization hint).

💡 The two classic interview traps: (1) checked exceptions don't roll back by default; (2) self-invocation skips the proxy so the transaction never starts. Both stem from understanding it's AOP-proxy-based.

@Transactional

🍃 Spring Boot · Data & JPA · 4 min read

The annotation that declares a transactional boundary. Key attributes:

Attribute	Purpose
`propagation`	How it joins/creates transactions
`isolation`	Concurrency visibility level
`readOnly`	Optimization for read queries
`rollbackFor` / `noRollbackFor`	Which exceptions trigger rollback
`timeout`	Max duration before rollback

@Transactional(readOnly = true)
public List<User> listUsers() { ... }

@Transactional(rollbackFor = Exception.class, timeout = 5)
public void process() { ... }

💡 Apply at method or class level (class = all public methods). See Propagation Types and Isolation Levels for the two most-tested attributes.

Propagation Types

🍃 Spring Boot · Data & JPA · 5 min read

Propagation defines how a transactional method behaves when called within an existing transaction.

Propagation	Behaviour
`REQUIRED` (default)	Join existing, or create a new one
`REQUIRES_NEW`	Always start a new tx (suspend the outer)
`SUPPORTS`	Join if one exists, else run non-tx
`MANDATORY`	Must run in an existing tx, else error
`NESTED`	Nested tx with savepoint
`NOT_SUPPORTED / NEVER`	Run non-tx / fail if tx exists

💡 Common case: use REQUIRES_NEW for an audit log that must commit even if the main transaction rolls back. Default REQUIRED is right for most service methods.

Isolation Levels

🍃 Spring Boot · Data & JPA · 5 min read

Isolation controls how/when one transaction's changes are visible to others — trading consistency against concurrency.

Level	Prevents
READ_UNCOMMITTED	Nothing (dirty reads possible)
READ_COMMITTED	Dirty reads
REPEATABLE_READ	Dirty + non-repeatable reads
SERIALIZABLE	All anomalies (incl. phantom reads)

Anomalies: dirty read (read uncommitted data), non-repeatable read (row changes between reads), phantom read (new rows appear).

@Transactional(isolation = Isolation.REPEATABLE_READ)

💡 Higher isolation = more consistency but less concurrency (more locking). READ_COMMITTED is the common default (Postgres/Oracle). Raise it only when you hit a specific anomaly.

Lazy Loading

🍃 Spring Boot · Data & JPA · 5 min read

Lazy loading defers fetching an association until it's actually accessed — saving queries when you don't need the related data.

@OneToMany(fetch = FetchType.LAZY)   // default for collections
private List<Order> orders;
// orders fetched only when order.getOrders() is called

⚠️ Two classic traps: (1) LazyInitializationException — accessing a lazy field after the session closes (outside the transaction); fix with JOIN FETCH or a DTO projection. (2) The N+1 problem — looping over N parents each lazily loading children = N+1 queries; fix with JOIN FETCH or @EntityGraph.

Eager Loading

🍃 Spring Boot · Data & JPA · 4 min read

Eager loading fetches an association immediately with its parent. Default for @ManyToOne/@OneToOne.

	Lazy	Eager
When loaded	On access	With parent
Default for	@OneToMany, @ManyToMany	@ManyToOne, @OneToOne
Risk	LazyInit / N+1	Loads unneeded data, big joins

💡 Best practice: make everything LAZY and fetch what you need explicitly per query (JOIN FETCH / @EntityGraph). Default EAGER on @ManyToOne is a common source of accidental over-fetching.

Spring Security

🍃 Spring Boot · Security · ★ Interview Topic · 10 min read

Spring Security is the framework for authentication (who are you?) and authorization (what can you do?). It works as a chain of servlet filters intercepting every request before it reaches your controller.

The Filter Chain — Visual

@Configuration @EnableWebSecurity
public class SecurityConfig {
    @Bean
    SecurityFilterChain chain(HttpSecurity http) throws Exception {
        http
          .csrf(csrf -> csrf.disable())                    // off for stateless APIs
          .authorizeHttpRequests(auth -> auth
              .requestMatchers("/api/public/**").permitAll()
              .requestMatchers("/api/admin/**").hasRole("ADMIN")
              .anyRequest().authenticated())
          .sessionManagement(s -> s.sessionCreationPolicy(STATELESS))
          .oauth2ResourceServer(o -> o.jwt(Customizer.withDefaults()));
        return http.build();
    }
    @Bean PasswordEncoder encoder() { return new BCryptPasswordEncoder(); }
}

Core Concepts

AuthenticationManager → UserDetailsService → PasswordEncoder verify credentials.
SecurityContextHolder holds the authenticated principal (per thread).
GrantedAuthority/roles drive authorization.

💡 Adding the starter secures everything by default. The modern config is a SecurityFilterChain bean (no more WebSecurityConfigurerAdapter). For REST APIs: stateless sessions + JWT + CSRF disabled.

Authentication

🍃 Spring Boot · Security · 4 min read

Authentication verifies who the user is — validating credentials (password, token, certificate) and establishing identity.

@Bean
UserDetailsService users(PasswordEncoder enc) {
    var user = User.withUsername("aftab")
        .password(enc.encode("secret")).roles("USER").build();
    return new InMemoryUserDetailsManager(user);
}
// in production: load from DB via a custom UserDetailsService

Method	Use
Form login / Basic	Traditional web / simple APIs
JWT (bearer token)	Stateless REST APIs
OAuth2 / OIDC	Delegated / SSO

💡 Implement a custom UserDetailsService to load users from your database, paired with a BCryptPasswordEncoder to verify hashed passwords.

Authorization

🍃 Spring Boot · Security · 4 min read

Authorization decides what an authenticated user may do — enforced at URL level or method level via roles/authorities.

// URL-level (in SecurityFilterChain)
.requestMatchers("/admin/**").hasRole("ADMIN")

// method-level (enable with @EnableMethodSecurity)
@PreAuthorize("hasRole('ADMIN')")
void deleteUser(Long id) { ... }

@PreAuthorize("hasAuthority('user:read') or #id == authentication.principal.id")
User get(Long id) { ... }

💡 hasRole('ADMIN') checks authority ROLE_ADMIN (the prefix is added automatically). Method security with SpEL (@PreAuthorize) enables fine-grained, expression-based rules including ownership checks.

OAuth 2.0

🍃 Spring Boot · Security · 5 min read

OAuth 2.0 is a delegated authorization framework — it lets an app access resources on a user's behalf without handling their password. OIDC adds an identity layer on top.

Role	Who
Resource Owner	The user
Client	Your app
Authorization Server	Issues tokens (Keycloak, Auth0, Google)
Resource Server	The API serving protected data

# Spring Boot as an OAuth2 Resource Server validating JWTs
spring.security.oauth2.resourceserver.jwt.issuer-uri=https://auth.example.com

💡 Authorization Code flow (with PKCE) is the standard for web/mobile. Your Spring Boot API is usually the Resource Server — it just validates the JWT issued by the auth server. See JWT Authentication for the token mechanics.

JWT Authentication

🍃 Spring Boot · Security · ★ Interview Topic · 9 min read

JWT (JSON Web Token) enables stateless authentication: the server issues a signed token the client sends on every request, so no server-side session is needed — ideal for REST APIs and microservices.

Login → Token → Access — Visual

Token Structure

Three base64 parts: header.payload.signature — header (algorithm), payload (claims: sub, roles, exp), signature (verifies integrity with a secret/key).

@Component
public class JwtAuthFilter extends OncePerRequestFilter {
    protected void doFilterInternal(HttpServletRequest req, ...) {
        String header = req.getHeader("Authorization");
        if (header != null && header.startsWith("Bearer ")) {
            String token = header.substring(7);
            if (jwtService.isValid(token)) {
                var auth = jwtService.toAuthentication(token);
                SecurityContextHolder.getContext().setAuthentication(auth);
            }
        }
        chain.doFilter(req, res);
    }
}

⚠️ JWTs are signed, not encrypted — never put secrets in the payload (it's readable). Keep expiry short, use refresh tokens, and remember you can't easily revoke a JWT before expiry (use short TTL + a denylist if revocation matters).

Role-Based Access Control (RBAC)

🍃 Spring Boot · Security · 4 min read

RBAC grants permissions based on roles assigned to users, rather than to individuals — the standard authorization model.

// roles → authorities; secure by role
.requestMatchers("/admin/**").hasRole("ADMIN")
.requestMatchers("/api/**").hasAnyRole("USER","ADMIN")

@PreAuthorize("hasRole('MANAGER')")
void approve() { ... }

💡 Model: User → Roles → Permissions (authorities). Spring distinguishes hasRole("X") (expects ROLE_X) from hasAuthority("perm:read") (exact match). For fine-grained control, grant authorities, not just roles.

Password Encoding

🍃 Spring Boot · Security · 4 min read

Never store passwords in plain text. Spring Security hashes them with a one-way, salted, slow algorithm via PasswordEncoder.

@Bean PasswordEncoder encoder() { return new BCryptPasswordEncoder(); }

String hash = encoder.encode(rawPassword);          // on signup
boolean ok = encoder.matches(rawPassword, hash);    // on login

⚠️ Use BCrypt (or Argon2/scrypt) — they're deliberately slow and salted to resist brute force. Never use MD5/SHA-1 for passwords (too fast). DelegatingPasswordEncoder (the default) supports upgrading algorithms over time.

Session Management

🍃 Spring Boot · Security · 4 min read

For session-based auth, Spring tracks logged-in users via a session cookie (JSESSIONID). You can control concurrency, fixation protection, and timeouts.

http.sessionManagement(s -> s
    .maximumSessions(1)                    // one session per user
    .sessionFixation().migrateSession());  // prevent fixation attacks
# scale sessions across instances → Spring Session + Redis
spring.session.store-type=redis

💡 Stateful sessions need sticky load balancing or a shared store (Spring Session + Redis) to scale horizontally. Modern REST APIs avoid this entirely by going stateless (next topic).

Stateless Applications

🍃 Spring Boot · Security · 4 min read

A stateless app keeps no server-side session — each request carries everything needed to authenticate (a JWT). Any instance can serve any request, enabling effortless horizontal scaling.

http.sessionManagement(s ->
    s.sessionCreationPolicy(SessionCreationPolicy.STATELESS));

	Stateful (session)	Stateless (JWT)
Server stores	Session	Nothing
Scaling	Sticky / shared store	Any instance
Auth carried by	Cookie	Bearer token

💡 Stateless + JWT is the default for microservices — it removes the session bottleneck. Trade-off: harder token revocation (mitigate with short TTL + refresh tokens).

REST API Security

🍃 Spring Boot · Security · 5 min read

Securing a REST API combines authentication, authorization, transport security, and input hardening.

HTTPS everywhere — encrypt in transit (TLS).
Stateless auth — JWT/OAuth2 bearer tokens; CSRF can be disabled for token-based APIs.
Authorization — least-privilege roles, method-level checks.
Input validation — @Valid, parameterized queries (no SQL injection).
Rate limiting & CORS — throttle abuse; restrict origins.
Security headers — HSTS, content-type, frame options.

http.cors(Customizer.withDefaults())
    .csrf(c -> c.disable())          // token-based, no cookies
    .headers(h -> h.frameOptions(f -> f.deny()));

💡 Follow the OWASP API Security Top 10. The big ones: broken object-level authorization (always check the caller owns the resource), excessive data exposure (use DTOs), and missing rate limiting.

OpenAPI Specification

🍃 Spring Boot · API Docs · 4 min read

OpenAPI (formerly Swagger Spec) is a standard, language-agnostic format for describing REST APIs — endpoints, parameters, schemas, responses — in JSON/YAML. Tools generate docs, clients, and tests from it.

# a slice of an OpenAPI doc
paths:
  /api/users/{id}:
    get:
      parameters: [{ name: id, in: path, required: true }]
      responses:
        '200': { description: OK, content: { application/json: {...} } }
        '404': { description: Not Found }

💡 OpenAPI is the contract; Swagger UI renders it as interactive docs. In Spring Boot, springdoc generates the spec from your annotated controllers automatically (next topic).

Swagger / OpenAPI Integration

🍃 Spring Boot · API Docs · ★ Interview Topic · 7 min read

Swagger UI gives you auto-generated, interactive API documentation. With springdoc-openapi, you add one dependency and get a live docs page that reads your controllers.

// pom.xml
<dependency>
  <groupId>org.springdoc</groupId>
  <artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
</dependency>
// then visit: /swagger-ui.html   and   /v3/api-docs

// enrich the docs with annotations
@Operation(summary = "Get a user by ID")
@ApiResponses({
    @ApiResponse(responseCode = "200", description = "Found"),
    @ApiResponse(responseCode = "404", description = "Not found")
})
@GetMapping("/{id}")
User get(@Parameter(description="user id") @PathVariable Long id) { ... }

💡 springdoc scans your controllers/DTOs and generates the OpenAPI spec at /v3/api-docs, rendered interactively at /swagger-ui.html. Add @Operation/@Schema for richer docs; secure or disable these endpoints in production.

Spring Boot Actuator

🍃 Spring Boot · Observability · ★ Interview Topic · 8 min read

Actuator exposes production-ready endpoints for monitoring and managing a running app — health, metrics, info, env, loggers — over HTTP or JMX. Essential for observability and Kubernetes probes.

Key Endpoints

Endpoint	Shows
`/actuator/health`	App + dependency health (DB, disk, Redis)
`/actuator/metrics`	JVM, HTTP, custom metrics
`/actuator/prometheus`	Metrics in Prometheus format
`/actuator/info`	Build/version info
`/actuator/loggers`	View/change log levels at runtime
`/actuator/env`	Configuration properties

# pom: spring-boot-starter-actuator
management.endpoints.web.exposure.include=health,info,metrics,prometheus
management.endpoint.health.show-details=when-authorized
management.endpoint.health.probes.enabled=true   # /health/liveness & /readiness

⚠️ Most endpoints are sensitive (env, heapdump, loggers) — only health/info are exposed by default. Lock the rest behind authentication and never expose them publicly. The liveness/readiness sub-endpoints map directly to K8s probes.

Health Checks

🍃 Spring Boot · Observability · 4 min read

/actuator/health aggregates the status of the app and its dependencies. Load balancers and orchestrators use it to route traffic only to healthy instances.

@Component
class RedisHealthIndicator implements HealthIndicator {
    public Health health() {
        return redisReachable()
            ? Health.up().withDetail("latency","2ms").build()
            : Health.down().build();
    }
}
# liveness vs readiness groups for Kubernetes
management.endpoint.health.group.readiness.include=db,redis

💡 Liveness = "is the app alive?" (restart if down). Readiness = "can it serve traffic?" (include dependency checks). Custom HealthIndicator beans are auto-aggregated into the overall status.

Metrics Monitoring

🍃 Spring Boot · Observability · 5 min read

Actuator uses Micrometer — a vendor-neutral metrics facade — to collect JVM, HTTP, and custom metrics and export them to Prometheus, Datadog, CloudWatch, etc.

// pom: micrometer-registry-prometheus → scraped at /actuator/prometheus
@Service
class OrderService {
    private final Counter ordersPlaced;
    OrderService(MeterRegistry reg) {
        this.ordersPlaced = reg.counter("orders.placed");
    }
    void place() { ordersPlaced.increment(); }   // custom business metric
}

💡 Micrometer is "SLF4J for metrics" — one API, many backends. You get HTTP latency, JVM memory/GC, and thread metrics out of the box; add counters/timers/gauges for business KPIs.

Logging

🍃 Spring Boot · Observability · 4 min read

Spring Boot uses SLF4J (facade) + Logback (default implementation) out of the box. Configure levels via properties; log to stdout for cloud-native apps.

private static final Logger log = LoggerFactory.getLogger(MyService.class);
log.info("Processing order {}", orderId);     // parameterized — no string concat
log.error("Failed for {}", orderId, exception);

# levels
logging.level.root=INFO
logging.level.com.example=DEBUG
logging.pattern.console=%d %-5level [%thread] %logger{36} - %msg%n

💡 Use parameterized logging ({}) — it skips string building when the level is disabled. In containers, log to stdout (12-factor) and let the platform aggregate. Add org.projectlombok:lombok + @Slf4j to skip the boilerplate logger line.

SLF4J

🍃 Spring Boot · Observability · 3 min read

SLF4J (Simple Logging Facade for Java) is an abstraction over logging frameworks. You code against SLF4J; the actual implementation (Logback, Log4j2) is swappable without changing code.

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
Logger log = LoggerFactory.getLogger(MyClass.class);

💡 SLF4J : Logback :: JPA : Hibernate — a facade and its implementation. Coding to the facade means you can swap Logback for Log4j2 by changing dependencies only.

Logback

🍃 Spring Boot · Observability · 4 min read

Logback is Spring Boot's default logging implementation. Customize it via logback-spring.xml — appenders (where logs go), encoders (format), and rolling policies.

<!-- logback-spring.xml: JSON to stdout for cloud -->
<appender name="JSON" class="ch.qos.logback.core.ConsoleAppender">
  <encoder class="net.logstash.logback.encoder.LogstashEncoder"/>
</appender>
<root level="INFO"><appender-ref ref="JSON"/></root>

💡 Use logback-spring.xml (not logback.xml) so Spring profile/property substitution works. For centralized logging (ELK/Loki), emit structured JSON and include a trace/correlation id (MDC).

Distributed Tracing & Observability

🍃 Spring Boot · Observability · ★ Interview Topic · 8 min read

In microservices, one user request spans many services. Distributed tracing stitches those hops into a single end-to-end trace so you can see where latency and errors occur. Observability rests on three pillars: metrics, logs, traces.

A Trace Across Services — Visual

// Micrometer Tracing (Spring Boot 3) propagates trace + span IDs
<dependency> io.micrometer:micrometer-tracing-bridge-otel </dependency>
<dependency> io.opentelemetry:opentelemetry-exporter-zipkin </dependency>
# logs auto-include [traceId, spanId] via MDC → correlate logs to traces

💡 The traceId flows through every service (propagated in HTTP headers), so you can follow one request across the whole system in Zipkin/Jaeger/Tempo. Correlate the three pillars: a slow trace → jump to its logs (same traceId) → check metrics for the spike.

OpenTelemetry

🍃 Spring Boot · Observability · 4 min read

OpenTelemetry (OTel) is the vendor-neutral CNCF standard for generating and exporting traces, metrics, and logs — one set of APIs/SDKs, any backend.

Instrument once with OTel; export to Jaeger, Tempo, Prometheus, Datadog, etc.
Spring Boot 3 integrates via Micrometer Tracing (bridge to OTel).
The OTel Collector receives, processes, and routes telemetry.

💡 OTel is replacing vendor-specific agents as the universal observability standard — instrument with OTel and you avoid lock-in to any monitoring vendor.

Caching

🍃 Spring Boot · Caching · ★ Interview Topic · 8 min read

Caching stores expensive results so repeated requests are served fast, reducing DB load and latency. Spring's cache abstraction makes it declarative — annotate a method and Spring handles the cache lookup/store.

Cache-Aside Flow — Visual

@EnableCaching   // on a @Configuration class

@Cacheable(value = "products", key = "#id")
public Product findById(Long id) { return repo.findById(id).get(); }  // runs only on miss

@CachePut(value = "products", key = "#p.id")   // update cache
public Product update(Product p) { ... }

@CacheEvict(value = "products", key = "#id")   // remove on delete
public void delete(Long id) { ... }

Annotation	Effect
`@Cacheable`	Return cached value or compute & store
`@CachePut`	Always run & update the cache
`@CacheEvict`	Remove entry/entries

💡 Spring's cache abstraction is provider-agnostic — back it with Caffeine (local), Redis (distributed), or others by adding a dependency. Always set a TTL and an eviction strategy to avoid stale data and unbounded growth.

Redis Integration

🍃 Spring Boot · Caching · 5 min read

Redis is an in-memory data store used as a distributed cache, session store, rate-limiter, and pub/sub broker. Spring Data Redis + the cache starter make it the standard distributed cache backend.

# pom: spring-boot-starter-data-redis + starter-cache
spring.cache.type=redis
spring.data.redis.host=localhost
spring.data.redis.port=6379
spring.cache.redis.time-to-live=600000   # 10 min TTL

// direct access via RedisTemplate
@Autowired StringRedisTemplate redis;
redis.opsForValue().set("key", "val", Duration.ofMinutes(5));
String v = redis.opsForValue().get("key");

💡 With spring.cache.type=redis, your @Cacheable methods transparently use Redis — so the cache is shared across all app instances (unlike a local in-JVM cache). Also great for shared sessions (Spring Session) and rate limiting.

Spring Boot Testing

🍃 Spring Boot · Testing · 5 min read

spring-boot-starter-test bundles JUnit 5, Mockito, AssertJ, and Spring Test. Spring Boot supports the full test pyramid: many fast unit tests, fewer integration tests, even fewer end-to-end.

Annotation	Loads
`@SpringBootTest`	Full application context (integration)
`@WebMvcTest`	Web layer only (controllers)
`@DataJpaTest`	JPA layer only (repositories + H2)
`@MockBean`	Replace a bean with a mock

💡 Use slice tests (@WebMvcTest, @DataJpaTest) for speed — they load only the relevant layer. Reserve @SpringBootTest for true integration tests; it boots the whole context and is slower.

Unit Testing

🍃 Spring Boot · Testing · 4 min read

Unit tests verify a single class in isolation, mocking its dependencies — no Spring context, so they're fast.

@ExtendWith(MockitoExtension.class)
class OrderServiceTest {
    @Mock OrderRepository repo;
    @InjectMocks OrderService service;

    @Test void placesOrder() {
        when(repo.save(any())).thenReturn(savedOrder);
        Order result = service.place(request);
        assertThat(result.getId()).isEqualTo(1L);
        verify(repo).save(any());
    }
}

💡 Constructor injection makes services trivially unit-testable: new OrderService(mockRepo) — no container needed. Follow Arrange-Act-Assert.

Integration Testing

🍃 Spring Boot · Testing · 5 min read

Integration tests verify multiple components working together (controller → service → repository → DB) with a real or near-real Spring context.

@SpringBootTest(webEnvironment = RANDOM_PORT)
@AutoConfigureMockMvc
class UserApiIT {
    @Autowired MockMvc mvc;

    @Test void createsUser() throws Exception {
        mvc.perform(post("/api/users")
              .contentType(APPLICATION_JSON)
              .content("{\"name\":\"Aftab\",\"email\":\"a@x.com\"}"))
           .andExpect(status().isCreated())
           .andExpect(jsonPath("$.id").exists());
    }
}

💡 MockMvc tests the web layer without a real server; TestRestTemplate/WebTestClient hit a running random-port server. Use Testcontainers for a real database instead of H2 (next).

JUnit 5

🍃 Spring Boot · Testing · 4 min read

JUnit 5 (Jupiter) is the standard testing framework — annotations, assertions, parameterized tests, and lifecycle hooks.

@Test void addsNumbers() {
    assertEquals(4, calc.add(2, 2));
    assertThrows(ArithmeticException.class, () -> calc.divide(1, 0));
}
@BeforeEach void setup() { ... }
@ParameterizedTest @ValueSource(ints = {1, 2, 3})
void isPositive(int n) { assertTrue(n > 0); }
@DisplayName("descriptive name") @Disabled @Nested

💡 Key annotations: @Test, @BeforeEach/@AfterEach, @BeforeAll, @ParameterizedTest, @Nested. Pair with AssertJ (assertThat(x).isEqualTo(y)) for fluent, readable assertions.

Mockito

🍃 Spring Boot · Testing · 4 min read

Mockito creates mock objects so you can test a class in isolation — stubbing dependency behaviour and verifying interactions.

@Mock UserRepository repo;
@InjectMocks UserService service;

// stub
when(repo.findById(1L)).thenReturn(Optional.of(user));
when(repo.save(any())).thenAnswer(inv -> inv.getArgument(0));

// verify interactions
verify(repo, times(1)).save(user);
verify(repo, never()).deleteById(any());

// capture arguments
ArgumentCaptor<User> captor = ArgumentCaptor.forClass(User.class);

💡 @Mock creates a mock; @InjectMocks injects mocks into the class under test. In Spring integration tests use @MockBean to replace a bean in the context with a mock.

TestContainers

🍃 Spring Boot · Testing · 5 min read

Testcontainers spins up real dependencies (PostgreSQL, Kafka, Redis) in Docker containers for tests — so you test against the real thing, not an in-memory substitute like H2.

@SpringBootTest
@Testcontainers
class UserRepoIT {
    @Container @ServiceConnection      // Boot 3.1 auto-wires datasource
    static PostgreSQLContainer<?> pg = new PostgreSQLContainer<>("postgres:16");

    @Autowired UserRepository repo;
    @Test void persists() { assertThat(repo.save(new User(...)).getId()).isNotNull(); }
}

💡 Testing against real Postgres catches dialect-specific bugs H2 would hide. Spring Boot 3.1's @ServiceConnection auto-configures the datasource from the container — no manual property wiring.

Spring Boot DevTools

🍃 Spring Boot · Testing · 3 min read

DevTools speeds up development with automatic restart on code changes, live reload for the browser, and dev-friendly defaults (disabled caching).

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-devtools</artifactId>
  <optional>true</optional>
</dependency>

⚠️ DevTools is for development only — it's automatically disabled in a packaged production jar. Don't rely on its restart in prod.

Spring Boot with Docker & Kubernetes

🍃 Spring Boot · Deployment · ★ Interview Topic · 9 min read

Spring Boot's fat JAR + embedded server makes it ideal for containers. Package it as a Docker image, then run it on Kubernetes for scaling and self-healing.

Dockerizing (Multi-Stage)

FROM maven:3.9-eclipse-temurin-21 AS build
WORKDIR /src
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package -DskipTests

FROM eclipse-temurin:21-jre
WORKDIR /app
COPY --from=build /src/target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","app.jar"]

Or skip the Dockerfile entirely with Buildpacks: ./mvnw spring-boot:build-image.

Kubernetes Deployment

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: app
          image: myrepo/app:1.0
          ports: [{ containerPort: 8080 }]
          env:
            - name: SPRING_PROFILES_ACTIVE
              value: prod
          livenessProbe:  { httpGet: { path: /actuator/health/liveness,  port: 8080 } }
          readinessProbe: { httpGet: { path: /actuator/health/readiness, port: 8080 } }

💡 The Spring-on-K8s checklist: multi-stage/layered image, externalize config via env vars/ConfigMaps/Secrets, map Actuator /health/liveness & /readiness to K8s probes, set -XX:MaxRAMPercentage for the container memory limit, and enable graceful shutdown (server.shutdown=graceful).

Spring Boot with Kubernetes

🍃 Spring Boot · Deployment · 4 min read

Beyond a basic Deployment, Spring Boot has first-class Kubernetes support.

Health probes — Actuator's liveness/readiness groups map to K8s probes.
Config — mount ConfigMaps/Secrets as env vars or files; spring-cloud-kubernetes can read them directly.
Graceful shutdown — server.shutdown=graceful drains in-flight requests on SIGTERM.
Service discovery — use native K8s Services/DNS (often instead of Eureka).

💡 On Kubernetes you often don't need Eureka or Spring Cloud Config — the platform provides service discovery (DNS) and config (ConfigMaps/Secrets) natively. See the Docker topic for the full deployment checklist.

Spring Boot with AWS

🍃 Spring Boot · Deployment · 4 min read

Spring Boot runs well across AWS compute options and integrates with AWS services via Spring Cloud AWS.

Run on	Notes
EC2	Run the jar / systemd; full control
ECS / Fargate	Containers, serverless option
EKS	Managed Kubernetes
Elastic Beanstalk	PaaS, quick deploys
Lambda	Spring Cloud Function + SnapStart

# Spring Cloud AWS: S3, SQS, Secrets Manager integration
spring.cloud.aws.region.static=ap-south-1
# use an IAM role on the instance — no static keys in code

💡 In production attach an IAM role to the compute (EC2/ECS/EKS) — the AWS SDK picks up temporary credentials automatically, so you never ship access keys. Pull DB credentials from Secrets Manager.

Microservices Architecture

🍃 Spring Boot · Microservices · ★ Interview Topic · 10 min read

Microservices split an application into small, independently deployable services, each owning a business capability and its data. Spring Cloud provides the supporting patterns.

Typical Topology — Visual

Core Patterns (Spring Cloud)

Pattern	Spring tool
API Gateway	Spring Cloud Gateway
Service Discovery	Eureka / Consul / K8s DNS
Centralized Config	Spring Cloud Config
Resilience	Resilience4j (circuit breaker)
Async messaging	Kafka / RabbitMQ
Tracing	Micrometer Tracing + OTel

💡 Key principles: one database per service (no shared DB), async events for decoupling, independent deployability, and design for failure (timeouts, retries, circuit breakers). The hard parts are data consistency (Saga pattern) and observability across services.

Service Discovery & API Gateway

🍃 Spring Boot · Microservices · ★ Interview Topic · 9 min read

In a dynamic system instances come and go with changing IPs. Service discovery lets services find each other by logical name; an API Gateway gives clients one entry point that routes to them.

Discovery Flow — Visual

Services register with the registry on startup and send heartbeats.
Callers look up a service by name and get healthy instances (client-side load balancing via Spring Cloud LoadBalancer).
The gateway routes external requests to services (often using the registry), handling auth, rate limiting, and cross-cutting concerns.

💡 On Kubernetes, native Services + DNS often replace Eureka. The gateway pattern still applies (Spring Cloud Gateway or an Ingress). Interview point: discovery removes hardcoded URLs; the gateway centralizes cross-cutting concerns.

Eureka Server

🍃 Spring Boot · Microservices · 4 min read

Netflix Eureka is a service registry. Services register with it and discover each other through it — the classic Spring Cloud discovery solution.

// the registry
@SpringBootApplication @EnableEurekaServer
public class RegistryApp { ... }

// a client service
@SpringBootApplication
public class OrderApp { ... }   // add spring-cloud-starter-netflix-eureka-client
# application.yml
eureka.client.service-url.defaultZone=http://localhost:8761/eureka

💡 Once registered, services call each other by name (http://order-service/...) with client-side load balancing — no hardcoded hosts. Run multiple Eureka nodes for HA.

API Gateway

🍃 Spring Boot · Microservices · ★ Interview Topic · 8 min read

An API Gateway is the single entry point for all client requests — routing them to backend services and handling cross-cutting concerns (auth, rate limiting, CORS, logging) in one place.

What It Centralizes

Routing

Path/host → service mapping, with load balancing via the registry.

Security

Authenticate/authorize once at the edge; pass identity downstream.

Rate limiting

Throttle abusive clients before they reach services.

Resilience & observability

Timeouts, retries, circuit breakers, request logging/tracing.

# Spring Cloud Gateway routes (application.yml)
spring.cloud.gateway.routes:
  - id: order-service
    uri: lb://order-service        # lb:// = load-balanced via registry
    predicates: [ Path=/api/orders/** ]
    filters: [ StripPrefix=2 ]

💡 Without a gateway, clients must know every service URL and each service re-implements auth/rate-limiting. The gateway is the place for edge concerns. Spring Cloud Gateway (reactive, Netty-based) is the modern choice over the deprecated Zuul.

Spring Cloud Gateway

🍃 Spring Boot · Microservices · 4 min read

Spring Cloud Gateway is the official, reactive (WebFlux/Netty) API gateway. It's built on routes = predicates (match) + filters (transform).

@Bean
RouteLocator routes(RouteLocatorBuilder b) {
    return b.routes()
        .route("users", r -> r.path("/api/users/**")
            .filters(f -> f.stripPrefix(2).requestRateLimiter(c -> ...))
            .uri("lb://user-service"))
        .build();
}

💡 Predicates decide which requests match (path, host, header, method); filters modify request/response (strip prefix, add headers, rate limit, circuit break). Being reactive, it handles high concurrency efficiently.

Config Server

🍃 Spring Boot · Microservices · 4 min read

Spring Cloud Config Server centralizes configuration for all microservices in one place (usually a Git repo) — so config is versioned, auditable, and changeable without redeploying.

// the server
@SpringBootApplication @EnableConfigServer
public class ConfigServerApp { ... }
# points at a git repo of {service}-{profile}.yml files
spring.cloud.config.server.git.uri=https://github.com/org/config-repo

// a client
spring.config.import=configserver:http://localhost:8888

💡 Combine with @RefreshScope + Actuator /refresh (or Spring Cloud Bus) to update config at runtime without restarts. On Kubernetes, ConfigMaps/Secrets often serve this role instead.

Circuit Breaker (Resilience4j)

🍃 Spring Boot · Microservices · ★ Interview Topic · 9 min read

A circuit breaker prevents cascading failures: when a downstream service keeps failing, the breaker "opens" and fails fast (or returns a fallback) instead of hammering the broken service and exhausting threads.

The Three States — Visual

@CircuitBreaker(name = "paymentService", fallbackMethod = "fallback")
@Retry(name = "paymentService")
public PaymentResult charge(Order order) {
    return paymentClient.charge(order);   // remote call
}
public PaymentResult fallback(Order order, Throwable t) {
    return PaymentResult.queued();        // graceful degradation
}

💡 States: CLOSED (normal) → too many failures → OPEN (fail fast) → after a wait → HALF-OPEN (trial calls) → success closes it. Combine with timeouts, retries, and bulkheads. This pattern is essential for microservice resilience.

Resilience4j

🍃 Spring Boot · Microservices · 5 min read

Resilience4j is the lightweight, functional fault-tolerance library for Spring Boot (replacing the deprecated Hystrix). It provides composable resilience patterns.

Pattern	Purpose
CircuitBreaker	Stop calling a failing service
Retry	Retry transient failures
RateLimiter	Cap call rate
Bulkhead	Isolate resource pools
TimeLimiter	Timeout slow calls

# application.yml
resilience4j.circuitbreaker.instances.paymentService:
  failure-rate-threshold: 50
  wait-duration-in-open-state: 10s
  sliding-window-size: 10

💡 Patterns compose: e.g. TimeLimiter + Retry + CircuitBreaker around one remote call. Resilience4j integrates with Actuator/Micrometer so you can monitor breaker state. See Circuit Breaker for the state machine.

Kafka Integration

🍃 Spring Boot · Messaging · ★ Interview Topic · 9 min read

Apache Kafka is a distributed event-streaming platform. Spring for Apache Kafka makes producing and consuming events simple — the backbone of event-driven microservices.

Producer → Topic → Consumers — Visual

// produce
@Service
class OrderPublisher {
    private final KafkaTemplate<String,OrderEvent> kafka;
    void publish(OrderEvent e) { kafka.send("orders", e.id(), e); }
}
// consume
@KafkaListener(topics = "orders", groupId = "billing")
void handle(OrderEvent e) { billingService.process(e); }

Key Concepts

Topic split into partitions for parallelism; ordering is guaranteed per partition.
Consumer groups — each group gets all messages; within a group, partitions are split across consumers.
Offsets track progress; messages are retained (replayable), unlike a queue.

💡 Kafka vs RabbitMQ: Kafka = high-throughput, retained, replayable event log (event sourcing, streaming); RabbitMQ = traditional message broker (routing, work queues). Use the message key to control partitioning and preserve per-entity ordering.

RabbitMQ Integration

🍃 Spring Boot · Messaging · 5 min read

RabbitMQ is a traditional message broker (AMQP) for decoupling services with queues. Spring AMQP makes producing/consuming straightforward.

// produce
rabbitTemplate.convertAndSend("exchange", "routing.key", orderEvent);

// consume
@RabbitListener(queues = "orders.queue")
void handle(OrderEvent e) { process(e); }

Core concepts: Exchange (routes by rules) → bindings → Queue → consumer. Exchange types: direct, topic, fanout, headers.

💡 RabbitMQ vs Kafka: RabbitMQ excels at flexible routing and work queues (message consumed once, then gone); Kafka excels at high-throughput, retained, replayable event streams. Pick by use case.

Event-Driven Architecture

🍃 Spring Boot · Messaging · 5 min read

In EDA, services communicate by emitting and reacting to events rather than calling each other directly — yielding loose coupling, scalability, and resilience.

// in-process events (single app) — Spring ApplicationEvents
publisher.publishEvent(new OrderPlacedEvent(order));

@EventListener
@Async
void onOrderPlaced(OrderPlacedEvent e) { sendEmail(e); }

// across services → publish to Kafka/RabbitMQ instead

Loose coupling — publishers don't know consumers.
Patterns — event notification, event-carried state transfer, event sourcing, CQRS.

💡 Use Spring's ApplicationEventPublisher for in-process decoupling; use a broker (Kafka/RabbitMQ) for cross-service events. The trade-off: eventual consistency and harder debugging (mitigate with tracing).

Async Processing

🍃 Spring Boot · Messaging · 4 min read

@Async runs a method on a separate thread so the caller doesn't block — for fire-and-forget work like emails, notifications, or report generation.

@Configuration @EnableAsync
class AsyncConfig {
    @Bean Executor taskExecutor() {
        var ex = new ThreadPoolTaskExecutor();
        ex.setCorePoolSize(4); ex.setMaxPoolSize(8); ex.setQueueCapacity(100);
        ex.initialize(); return ex;
    }
}
@Async
public CompletableFuture<Report> generate() { ... }

⚠️ @Async works via a proxy — like @Transactional, self-invocation doesn't work, and the method should return void or CompletableFuture. Always define a custom Executor (the default is unbounded) and handle exceptions (they won't propagate to the caller).

CompletableFuture

🍃 Spring Boot · Messaging · 4 min read

CompletableFuture enables non-blocking, composable async pipelines — combine several async calls without blocking threads.

// run two service calls in parallel, then combine
var user    = CompletableFuture.supplyAsync(() -> userService.find(id));
var orders  = CompletableFuture.supplyAsync(() -> orderService.byUser(id));
CompletableFuture.allOf(user, orders).join();
var dto = new ProfileDto(user.join(), orders.join());

💡 Combine with @Async methods returning CompletableFuture to parallelize independent calls (e.g. fan-out to several services) and cut total latency. Chain with thenApply/thenCompose/exceptionally.

Scheduling

🍃 Spring Boot · Messaging · 4 min read

@Scheduled runs tasks on a timer — cron, fixed rate, or fixed delay — for cleanups, reports, and polling.

@Configuration @EnableScheduling
class SchedulingConfig {}

@Scheduled(cron = "0 0 2 * * *")        // every day at 02:00
void nightlyCleanup() { ... }

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

@Scheduled(fixedDelay = 5000)            // 5s after the previous finishes
void process() { ... }

⚠️ Default scheduling uses a single thread (tasks queue up). In a multi-instance deployment, every instance runs the job — use ShedLock or a distributed scheduler (Quartz) to ensure it runs once cluster-wide.

Batch Processing

🍃 Spring Boot · Messaging · 4 min read

Spring Batch processes large volumes of data in chunks with restartability, retry/skip, and transaction management — for ETL, migrations, and report generation.

// a job = steps; a step = read → process → write (chunked)
@Bean
Step step(JobRepository repo, PlatformTransactionManager tx) {
    return new StepBuilder("step", repo)
        .<Input,Output>chunk(100, tx)        // commit every 100 records
        .reader(itemReader())
        .processor(itemProcessor())
        .writer(itemWriter())
        .build();
}

💡 Spring Batch handles the hard parts of bulk processing: chunked commits, restart-from-failure (job repository tracks state), skip/retry policies, and parallel/partitioned steps for scale.

File Upload & Download

🍃 Spring Boot · Web Clients · 4 min read

Handle multipart uploads with MultipartFile and stream downloads with Resource/ResponseEntity.

// upload
@PostMapping("/upload")
String upload(@RequestParam("file") MultipartFile file) throws IOException {
    storageService.store(file.getBytes(), file.getOriginalFilename());
    return "ok";
}
// download
@GetMapping("/download/{name}")
ResponseEntity<Resource> download(@PathVariable String name) {
    return ResponseEntity.ok()
        .header(CONTENT_DISPOSITION, "attachment; filename=\"" + name + "\"")
        .body(storageService.loadAsResource(name));
}

# limits
spring.servlet.multipart.max-file-size=10MB
spring.servlet.multipart.max-request-size=10MB

💡 For large files or web apps, upload directly to object storage (S3) via presigned URLs instead of proxying bytes through your server — saves memory and bandwidth. Validate file type/size to prevent abuse.

WebClient vs RestTemplate

🍃 Spring Boot · Web Clients · ★ Interview Topic · 8 min read

Both make HTTP calls to other services. RestTemplate is the classic synchronous (blocking) client — now in maintenance mode. WebClient is the modern, non-blocking, reactive client (works for both sync and async).

Comparison

	RestTemplate	WebClient
Model	Synchronous, blocking	Async, non-blocking (reactive)
Threads	One per call (blocks)	Few event-loop threads
Status	Maintenance mode	Recommended
Streaming	Limited	Yes (Flux)

// WebClient — async
Mono<User> user = webClient.get()
    .uri("/users/{id}", id)
    .retrieve()
    .bodyToMono(User.class);

// WebClient — blocking (sync) when you need it
User u = webClient.get().uri("/users/{id}", id)
    .retrieve().bodyToMono(User.class).block();

// RestTemplate — classic blocking
User u2 = restTemplate.getForObject("/users/{id}", User.class, id);

💡 Interview answer: "RestTemplate is synchronous and in maintenance mode; WebClient is the modern non-blocking client (from WebFlux) that also works synchronously via .block(). For new code, use WebClient." It shines for parallel/streaming calls without thread-per-request cost.

RestTemplate

🍃 Spring Boot · Web Clients · 3 min read

The classic synchronous HTTP client for calling REST APIs. Simple and familiar, but blocking and now in maintenance mode.

RestTemplate rt = new RestTemplate();
User u = rt.getForObject(url, User.class);
ResponseEntity<User> resp = rt.getForEntity(url, User.class);
User created = rt.postForObject(url, request, User.class);
rt.exchange(url, HttpMethod.PUT, new HttpEntity<>(body), Void.class);

💡 Still fine for simple, low-concurrency synchronous calls. For new projects prefer WebClient (or the Spring 6 declarative HTTP Interface clients). See WebClient vs RestTemplate.

Reactive Programming (WebFlux)

🍃 Spring Boot · Web Clients · 5 min read

Spring WebFlux is the reactive, non-blocking web stack (alternative to Spring MVC). Built on Project Reactor (Mono/Flux), it handles high concurrency with few threads.

@RestController
class UserController {
    @GetMapping("/users/{id}")
    Mono<User> get(@PathVariable String id) {      // 0..1 async
        return userService.findById(id);
    }
    @GetMapping(value="/users", produces=TEXT_EVENT_STREAM_VALUE)
    Flux<User> stream() { return userService.streamAll(); }  // 0..N stream
}

	Spring MVC	WebFlux
Model	Blocking, thread-per-request	Non-blocking, event loop
Best for	Most apps, simpler	High concurrency, streaming
Server	Tomcat	Netty

⚠️ Reactive isn't automatically faster — it scales better under high concurrency / I/O-bound load but adds complexity (the whole chain must be non-blocking; one blocking call ruins it). For typical CRUD apps, Spring MVC is simpler and plenty fast. Java 21 virtual threads narrow the gap further.

Spring Boot Best Practices

🍃 Spring Boot · Best Practices · ★ Interview Topic · 8 min read

✓ Do

Constructor injection (not field)
Keep controllers thin, logic in services
Use DTOs at the API boundary (not entities)
@Transactional on the service layer
Validate input with @Valid
Global exception handling (@RestControllerAdvice)
Externalize config; profiles per env
Lazy associations + fetch explicitly
Actuator + metrics + structured logging

✗ Avoid

Field injection & @Autowired everywhere
Business logic in controllers
Exposing entities directly
EAGER fetching / N+1 queries
ddl-auto=update in production
Secrets in code / properties in Git
Catching & swallowing exceptions
Stateful singletons

💡 The recurring themes: clear layering, DTO boundaries, declarative cross-cutting concerns (tx, validation, exceptions), externalized config, and observability built in. These are exactly what senior interviews probe for.

Spring Boot Performance Tuning

🍃 Spring Boot · Best Practices · ★ Interview Topic · 9 min read

Performance tuning spans the database, caching, threads/connections, and the JVM. Always profile first to find the real bottleneck.

Database (biggest wins)

Fix N+1 (JOIN FETCH / @EntityGraph), add indexes, paginate, tune the HikariCP pool, use projections/DTOs.

Caching

@Cacheable hot reads (Redis/Caffeine) with TTL to offload the DB.

Connection pools

Right-size HikariCP & HTTP client pools; avoid exhaustion under load.

Async & parallel

Offload non-critical work (@Async); parallelize independent calls (CompletableFuture).

JVM/GC

Right heap (-Xmx/MaxRAMPercentage), G1/ZGC, reduce allocation.

Startup

Lazy init, AOT/native image (GraalVM), CDS for faster boot.

# HikariCP tuning
spring.datasource.hikari.maximum-pool-size=20
spring.datasource.hikari.connection-timeout=3000
spring.jpa.properties.hibernate.jdbc.batch_size=50    # batch inserts

💡 In Spring Boot apps the bottleneck is usually the database — N+1 queries, missing indexes, or pool exhaustion. Measure with Actuator metrics + slow-query logs + a profiler before optimizing anything else.

Security Best Practices

🍃 Spring Boot · Best Practices · 5 min read

HTTPS/TLS everywhere; HSTS & security headers.
Hash passwords with BCrypt/Argon2; never store plaintext.
Stateless auth (JWT/OAuth2) with short-lived tokens.
Validate & sanitize all input; parameterized queries (no SQLi).
Least privilege RBAC; check object-level ownership.
Secrets in a vault/secret manager, never in Git.
Dependency scanning (OWASP Dependency-Check); patch CVEs.
Rate limiting & CORS; lock down Actuator endpoints.

💡 Follow the OWASP Top 10. The most common real-world misses: broken object-level authorization, secrets in source control, and exposed/unsecured Actuator endpoints.

Production Deployment Strategies

🍃 Spring Boot · Best Practices · 6 min read

A consolidated checklist for shipping Spring Boot to production safely.

Build & Package

Layered/multi-stage Docker image, pinned tags (git SHA), non-root, scanned.

Config

Externalized per env, profiles, secrets from a vault — never in the image.

Resilience

Health probes, graceful shutdown, ≥2 replicas, circuit breakers, autoscaling.

Observability

Actuator + Prometheus metrics, centralized logs, distributed tracing, alerts.

Data

Flyway/Liquibase migrations, ddl-auto=validate, backups, connection pooling.

Release

CI/CD, rolling / blue-green / canary, automated rollback.

# production essentials
spring.jpa.hibernate.ddl-auto=validate     # never create/update
server.shutdown=graceful
management.endpoints.web.exposure.include=health,info,prometheus

💡 Production-ready in one line: externalized config & secrets, DB migrations with validate, health probes + graceful shutdown, full observability, and automated rolling deploys from CI/CD with rollback.