Microservices Interview Questions

Spring Boot simplifies microservice development through auto-configuration, starter dependencies, and embedded servers. It helps teams build independently deployable REST services with little setup. Spring Cloud adds common support for configuration, discovery, routing, and resilience.

Services communicate synchronously through REST, gRPC, or declarative HTTP clients when an immediate response is needed. They communicate asynchronously through Kafka, RabbitMQ, or another broker when loose coupling and resilience are more important. The choice depends on latency, delivery, ordering, and failure requirements.

RestTemplate is a traditional blocking HTTP client. WebClient supports non-blocking, asynchronous, and streaming communication. OpenFeign is a declarative client where an interface and annotations describe HTTP calls. Select the client based on whether the service is synchronous, reactive, streaming, or interface-oriented.

RestTemplate is a mature blocking client in maintenance mode. For new synchronous Spring applications, RestClient is the modern choice, while WebClient is preferred for reactive, asynchronous, and streaming use cases. Existing RestTemplate applications can continue running and should be migrated based on business need rather than changed blindly.

Register service instances with a discovery system such as Eureka, Consul, or Kubernetes service discovery. Each instance registers its logical name, address, and health status. Clients call the service name, and a load balancer selects a healthy instance instead of using a hardcoded host and port.

An API gateway is the client-facing entry point for multiple microservices. It routes requests and can centralize authentication, rate limiting, logging, request transformation, and cross-cutting policies. Spring Cloud Gateway is commonly used in Spring-based systems, but the gateway should not contain all business logic.

Use Spring Cloud Config Server or a deployment platform to store shared and environment-specific configuration in one managed location. Services retrieve settings during startup or through a controlled refresh process. Keep passwords and tokens in a secret manager rather than in a normal Git repository.

A circuit breaker prevents repeated calls to a dependency that is failing or responding slowly. In the closed state calls flow normally, the open state rejects calls quickly, and the half-open state allows limited test calls. Resilience4j or Spring Cloud Circuit Breaker can provide this behaviour.

Configure connection and response timeouts on WebClient, RestClient, or OpenFeign. Use a limited Resilience4j retry policy with exponential backoff and jitter for temporary failures. Retry only safe or idempotent operations; blindly retrying a payment or order command can create duplicates.

The bulkhead pattern isolates resources so one failing dependency cannot exhaust the whole service. Use separate thread pools, semaphores, queues, or connection limits for different downstream operations. A slow recommendation service should not consume all capacity needed for payments or authentication.

Instrument services with Micrometer Tracing or OpenTelemetry and export spans to systems such as Zipkin, Jaeger, or Tempo. A trace ID identifies one request across services, while span IDs identify individual operations. Traces help locate cross-service latency, retries, and failures that ordinary logs cannot show alone.

Create or accept a correlation ID at the gateway or first service and propagate it through an HTTP header such as X-Correlation-ID. Forward it in downstream calls and message metadata, then add it to the logging context. Do not place credentials or personal information in the ID.

Use timeouts, limited retries, circuit breakers, fallbacks, and bulkheads to stop one failure spreading through the system. Optional work can be moved to an asynchronous queue, while a reduced response can serve the user. If earlier distributed steps already succeeded, use a compensating action or Saga workflow.

Each service should normally own its database and publish business events instead of sharing tables. Use local transactions with an Outbox pattern, Saga coordination, idempotent consumers, and reconciliation jobs. Avoid distributed database transactions unless the operational and performance costs are truly justified.

Saga divides a distributed business transaction into a sequence of local transactions. Each successful step triggers the next event or command. If a later step fails, a compensating transaction reverses or offsets the earlier business effect. A Saga can be coordinated centrally or through event choreography.

The Outbox pattern writes a business change and its outgoing event to an outbox table in the same local database transaction. A separate publisher reads pending outbox rows and sends them to Kafka or another broker. This prevents the database update from succeeding while the related event is lost.

Require an idempotency key for retryable commands such as payment or order creation. Store the key with the result and return the stored result when the same request is repeated. A database unique constraint should also protect against concurrent duplicate requests.

Include a unique event ID in every message and store processed IDs in the consumer’s database. Check the ID before applying the business operation and make the update idempotent. When possible, perform the duplicate check and business update in the same local transaction.

Use OAuth 2.0 client credentials, signed JWT access tokens, or mutual TLS. Each service validates the token or certificate, including signature, issuer, audience, expiry, scopes, and rotation rules. Store credentials and private keys in a secure secret-management system.

Return a reduced but useful response when an optional dependency is unavailable. Use cached data, safe defaults, fallback responses, or temporarily disable non-critical features. Circuit breakers and feature flags can activate fallback behaviour without making the entire request fail.