Spring Boot Annotations Explained: What Interviewers Expect You to Know
From @SpringBootApplication to @Transactional — the annotations you use every day, and how to explain them clearly in an interview.
Sample article
Common microservices interview questions for Java developers — service communication, API gateways, service discovery, resilience, data management and how to explain your own architecture.
Microservices questions test whether you understand trade-offs, not whether you can list tools. Use these answers as a starting point, then connect each one to a project you have worked on.
1. What are microservices, and when should you not use them?
Microservices split an application into small, independently deployable services, each owning one business capability and its own data. They help large teams deploy and scale parts independently. They also add network calls, distributed failures and operational overhead — so for a small team or an early-stage product, a well-structured monolith is often the better choice.
2. How do services communicate?
- Synchronous — REST (or gRPC) calls, e.g. with RestClient, WebClient or OpenFeign. Simple, but the caller waits and is affected if the other service is slow.
- Asynchronous — events through a message broker such as Kafka or RabbitMQ. Services are decoupled and more resilient, at the cost of eventual consistency.
3. What does an API gateway do?
An API gateway (for example Spring Cloud Gateway) is the single entry point for clients. It routes requests to the right service and centralises cross-cutting concerns such as authentication, rate limiting, CORS and request logging.
4. What is service discovery?
Service instances start, stop and move, so their addresses change. With service discovery, instances register themselves (for example with Eureka or Consul) and callers look them up by name. On Kubernetes, the platform’s own Services and DNS usually provide this.
5. How do you make services resilient?
Assume other services will fail. Use timeouts on every remote call, retries with backoff for temporary errors, and a circuit breaker that stops calling a failing service and returns a fallback. Resilience4j provides these patterns for Spring Boot.
@CircuitBreaker(name = "inventory", fallbackMethod = "inventoryFallback")
public StockResponse checkStock(String productId) {
return inventoryClient.getStock(productId);
}
private StockResponse inventoryFallback(String productId, Throwable ex) {
return StockResponse.unknown(productId); // degrade gracefully
}6. How is data managed across services?
Each service owns its database; other services access that data only through its API or events. Because a single database transaction cannot span services, business processes that touch several services use the Saga pattern — a sequence of local transactions with compensating actions if a step fails.
7. How do you trace a request across services?
Use distributed tracing: a trace ID is created at the entry point and passed along with every call, so logs and spans from all services can be joined. In Spring Boot 3 this is done with Micrometer Tracing, exporting to tools like Zipkin or OpenTelemetry-compatible backends.
8. How do you manage configuration?
Keep configuration outside the code: profiles and environment variables for each environment, and a central source such as Spring Cloud Config or Kubernetes ConfigMaps. Secrets belong in a secret store, never in the repository.
This is a sample article published as a starter resource. Verify technical details against official documentation for the versions you use.