Spring Boot Microservices Interview Questions India 2026: Architecture, APIs, and Cloud Native

Microservices vs monolith interview questions:

1. Monolithic architecture: All features of an application are deployed as a single unit. One codebase, one database, one deployment. Advantages: simpler development, testing, and deployment (one application to manage); easier debugging (single process); no network latency between components. Disadvantages: harder to scale individual components (you must scale the entire application); a bug in one module can bring down the entire system; as the team grows, a monolith becomes a bottleneck (merge conflicts, slower releases, harder to onboard new engineers).

2. Microservices architecture: The application is split into small, independently deployable services, each responsible for a specific business capability. Each service has its own database (database per service pattern). Services communicate via REST APIs (synchronous) or messaging (asynchronous, e.g., Kafka). Advantages: each service can be scaled independently; different services can use different languages and databases; teams can own and deploy services independently. Disadvantages: distributed systems are complex (network latency, partial failures, distributed transactions); operational overhead (many services to monitor, deploy, and maintain).

3. When to choose each: Monolith: for startups and early-stage products (move fast; refactor later); teams of fewer than 10-15 engineers where communication overhead of microservices outweighs benefits; when the domain is not yet well-understood (premature decomposition is costly to fix). Microservices: for large teams (different teams can own different services); for domains with clearly separable business capabilities (order management, payment processing, inventory); when different services have different scaling requirements. The pragmatic choice: start with a modular monolith (well-structured modules within one codebase) and extract services when a specific module needs to scale independently.

Spring Boot fundamentals:

1. What is Spring Boot? Spring Boot is an opinionated framework built on top of the Spring Framework. It provides auto-configuration (sensible defaults based on the libraries on the classpath), embedded server (Tomcat, Jetty, or Undertow built in; no WAR deployment needed), starter dependencies (spring-boot-starter-web includes everything needed for a web application), and Actuator (production-ready monitoring endpoints: /actuator/health, /actuator/metrics, /actuator/info).

2. @SpringBootApplication: This single annotation on the main class combines three annotations: @Configuration (this class defines beans), @EnableAutoConfiguration (trigger Spring Boot's auto-configuration), @ComponentScan (scan the package for Spring components). Spring Boot auto-configuration: when spring-boot-starter-data-jpa is on the classpath, Spring Boot automatically configures a DataSource, EntityManagerFactory, and JpaTransactionManager from your application.properties.

3. Bean lifecycle and @Component, @Service, @Repository, @Controller: All four are stereotypes of @Component: they mark a class for auto-detection and bean creation. The distinction is semantic: @Repository (data access layer; also translates data access exceptions), @Service (business logic), @Controller/@RestController (web layer). @Autowired: injects a dependency; constructor injection is preferred over field injection (immutable dependencies, easier testing).

4. Spring Boot properties and profiles: application.properties or application.yml: configuration for the application (database URL, server port, logging level). Profiles (spring.profiles.active): separate configuration files for each environment (application-dev.yml, application-prod.yml). In production: use environment variables to override sensitive values (database password, API keys) rather than committing them to application-prod.yml.

Spring Cloud microservices patterns:

1. Service discovery with Eureka: In a microservices system, services need to find each other by name, not by IP (IPs change as containers restart and scale). Eureka Server: a service registry where each microservice registers itself on startup. Eureka Client (@EnableEurekaClient): each microservice registers with Eureka and can discover other services by name (e.g., call the ORDER-SERVICE without knowing its IP). Alternatives: Consul, Kubernetes service discovery (when running on K8s, you typically use K8s services instead of Eureka).

2. API Gateway with Spring Cloud Gateway: All client requests enter through the API Gateway. It routes requests to the appropriate downstream microservice, applies cross-cutting concerns (authentication, rate limiting, request logging, CORS), and provides a single entry point for clients. Spring Cloud Gateway replaces the older Netflix Zuul. WebFlux-based (reactive, non-blocking): handles high concurrency efficiently.

3. Centralised configuration with Spring Cloud Config: Config Server stores configuration for all microservices in a Git repository. Each microservice fetches its configuration from the Config Server on startup. Benefit: change a configuration value in Git and the Config Server can push the update to all microservices without redeployment (with @RefreshScope). Avoids hardcoding configuration in each service's JAR.

4. Circuit breaking with Resilience4j: A circuit breaker prevents cascading failures. If the PAYMENT-SERVICE is down or slow, the circuit breaker in the ORDER-SERVICE 'opens' and stops calling the PAYMENT-SERVICE for a period (fast-fail with a fallback response). After a timeout, it tests again with a few requests ('half-open' state); if those succeed, it 'closes' and normal operation resumes. Resilience4j also provides: retry (retry failed calls N times before failing), rate limiter (limit the number of calls per second), and bulkhead (limit concurrent calls to prevent resource exhaustion).

Advanced Spring Boot microservices topics:

1. Synchronous communication (REST): One service calls another's REST API directly. Tools: RestTemplate (legacy; blocking), WebClient (reactive; non-blocking, preferred for high concurrency), OpenFeign (declarative REST client; write an interface with @FeignClient and Spring generates the implementation). Trade-offs: tight coupling (if the downstream service is down, the upstream call fails); simpler for request-response patterns.

2. Asynchronous communication with Kafka: Kafka is a distributed event streaming platform. Producer sends messages to a Kafka topic; consumer reads from the topic. The producer does not wait for the consumer to process the message (fire and forget). Trade-offs: loose coupling (the producer does not care if the consumer is temporarily down; messages are stored in Kafka until consumed); better scalability (multiple consumer instances can process in parallel); but eventual consistency (the consumer processes the message at some point in the future, not immediately). Typical use in Indian fintech: an ORDER-SERVICE publishes an 'order_placed' event to Kafka; the PAYMENT-SERVICE, NOTIFICATION-SERVICE, and INVENTORY-SERVICE each consume the event independently.

3. Distributed transactions: When an operation spans multiple microservices and their separate databases, you cannot use a single database transaction. Solutions: Saga pattern (a sequence of local transactions; each service does its work and publishes an event; if a step fails, compensating transactions undo the previous steps); Two-Phase Commit (2PC, rarely used: requires all participants to lock resources until the coordinator confirms commit; very poor availability). Choreography-based Saga: each service publishes events and reacts to other services' events (no central coordinator). Orchestration-based Saga: a central orchestrator tells each service what to do and manages the overall transaction.