Knowledge Your Way: Top scenario based microservices interview questions

1. Service Communication and Data Consistency

If a microservice in the middle of a synchronous REST request chain fails, failure recovery can be handled using resilience patterns to prevent cascading failures and improve system stability. Here’s how:

1. Implement Circuit Breaker Pattern (Prevent System Overload)

The circuit breaker prevents the system from repeatedly calling a failing service, which could lead to further slowdowns.

Solution: Use Resilience4j Circuit Breaker to monitor failures and temporarily stop calls to the failing service.

@CircuitBreaker(name = "orderService", fallbackMethod = "fallbackResponse")

public String callOrderService() {

return restTemplate.getForObject("http://order-service/api/orders", String.class);

}

public String fallbackResponse(Exception ex) {

return "Fallback: Order Service is unavailable, please try again later.";

}

📌 How it works:

Real time example - In simple terms, a circuit breaker is like a safety switch in a system that prevents it from repeatedly trying to do something that’s failing, which could make the situation worse.

Imagine you're trying to plug an appliance into a socket, but the socket keeps sparking (failing). If you keep plugging it in, it could cause damage. So, you use a circuit breaker to cut off power to that socket temporarily. This gives the system time to recover before you try again.

In the same way, in a microservices architecture, a circuit breaker monitors calls between services. If one service is failing (for example, it’s too slow or unavailable), the circuit breaker “opens” and stops the system from trying to call that service repeatedly. This helps avoid overloading the failing service and gives it time to recover.

Once the service seems to be working again (after a timeout or a check), the circuit breaker "closes" and the system can try calling the service again.

If the order-service fails multiple times, the circuit breaker opens and stops further calls.

Once the service recovers, the circuit breaker closes, allowing traffic again.

2. Use Retry Mechanism for Temporary Failures

If the failure is intermittent, retrying after a short delay can resolve the issue.

Solution: Use Spring Retry to automatically retry failed requests.

@Retryable(value = {HttpServerErrorException.class}, maxAttempts = 3, backoff = @Backoff(delay = 2000))

public ResponseEntity<String> callPaymentService() {

return restTemplate.getForEntity("http://payment-service/api/payments", String.class);

}

📌 How it works:

Real time example: In simple terms, imagine you're trying to make a phone call, but the line is temporarily bad and the call fails. Instead of hanging up immediately, you try calling again after a short pause, and eventually, the connection works.

In a system, sometimes a failure is just temporary, like a service being momentarily slow or unavailable. Rather than giving up on the first failure, Spring Retry automatically tries to make the request again after a brief delay. It keeps retrying a few times before it gives up, hoping that the problem will resolve itself in the meantime.

This approach works well for intermittent issues, where a retry could succeed after a short delay.

- If the `payment-service` fails, the request will retry up to **3 times** with a **2-second delay**.

3. Set Timeouts to Avoid Blocking Requests

If a service is unresponsive, requests may hang indefinitely. Timeouts ensure that failing services do not slow down the entire system.

Solution: Configure timeouts for outgoing HTTP calls.

@Bean

public HttpComponentsClientHttpRequestFactory clientHttpRequestFactory() {

HttpComponentsClientHttpRequestFactory factory = new HttpComponentsClientHttpRequestFactory();

factory.setConnectT`imeout(3000); // 3 seconds

factory.setReadTimeout(5000); // 5 seconds

return factory;

}

How it works:

Real time example : In simple terms, imagine you're waiting in line at a coffee shop, and the barista is taking too long to make your coffee. Instead of waiting forever, you set a limit on how long you're willing to wait. If the coffee isn't ready in that time, you walk away.

In a system, when one service takes too long to respond, it can slow down everything else. Timeouts are like setting a waiting limit for requests. If a service doesn’t respond within the set time, the system stops waiting and moves on, preventing other parts of the system from getting stuck. This keeps the system running smoothly instead of letting one slow service bring everything to a halt.

If the service does not respond within 5 seconds, the request is aborted.

4. Implement Fallback Mechanisms
When a service fails, return a default response or use a cached response instead.
Solution: Store recent successful responses in a cache (e.g., Redis) and serve them when the service is down.

public String fallbackOrderDetails(String orderId, Throwable ex) {
return redisCache.get("order_" + orderId, String.class); // Return cached order details
}
How it works:

Real time example: Absolutely! Here's the same example using Celsius instead of Fahrenheit:
Example: Weather App with Celsius
Imagine you're using a weather app that fetches the current temperature from an external service. If the weather service goes down, instead of showing an error, the app can show the last known weather report (stored in cache) while the service is unavailable.
For example:
- Last known report: "Sunny, 24°C"
- If the service fails, the app will show "Sunny, 24°C" from the cache, instead of displaying an error message or a blank screen.
This way, the user still gets a helpful, up-to-date temperature reading based on the last successful data retrieval, even if the weather service is temporarily down. It ensures the app remains useful while the service is unavailable.

If the order service is down, return the last successful response from Redis.

5. Use Asynchronous Processing for Non-Critical Requests

Instead of synchronous REST calls, consider event-driven communication (Kafka, RabbitMQ) for better resilience.

Solution: Instead of waiting for a response, publish an event to a message queue.

rabbitTemplate.convertAndSend("order_exchange", "order.created", order);

How it works:

Real time example:

Imagine you're signing up for a new account on a website. Normally, after you fill in your details, the website might wait for each step to complete, such as:

Create User in the database
Send Email for confirmation

In a synchronous system, the website waits for the email service to send the confirmation email before showing you a success message. If the email service is slow or down, the whole user registration might fail, and you’ll have a bad experience.

With event-driven communication, the process works like this:

User Registration Service receives your details and immediately publishes an event like "UserRegistered" to a message queue (Kafka or RabbitMQ).
The Email Service listens for "UserRegistered" events, and when it gets one, it sends a confirmation email.

The order request is queued instead of blocking the request.
Other microservices (e.g., payment, inventory) consume the event asynchronously
.
Summary: Key Recovery Strategies

Conclusion
To handle failure recovery in a synchronous REST-based microservices architecture:
- Use Circuit Breaker to prevent repeated calls to a failing service.
- Implement Retry for temporary failures with exponential backoff.
- Set Timeouts to avoid blocking the request chain.
- Use Fallback Responses or Cache for missing data.
- Move to Asynchronous Communication for non-critical requests. Q2: In an e-commerce application, an order service calls payment and inventory services. How do you ensure that the order is placed only if both payment and inventory updates are successful? Ensuring that an order is placed only if both payment and inventory updates are successful in a microservices architecture requires a strategy for distributed transactions and data consistency. Since microservices do not share a single database, traditional ACID transactions are not feasible. Below are effective solutions:
- . Use the Saga Pattern (Recommended)
  The Saga Pattern ensures data consistency across multiple services through a sequence of compensating transactions.
  Two Saga Approaches:
  Choreography (Event-Driven)
  Orchestration (Centralized Controller)
  
  1. Orchestration
  Orchestration is like a central conductor in a symphony. A central service or orchestrator controls the entire workflow and tells each service what to do in a specific order.
- Steps in Orchestration:
- 4. Use Idempotency to Prevent Duplicate Orders
  If retry mechanisms exist, they may cause duplicate orders.
  Solution: Add an idempotency key (unique request ID)
if (orderRepository.existsByTransactionId(request.getTransactionId())) {
return ResponseEntity.status(HttpStatus.CONFLICT).body("Duplicate request");
}

5. Use Dead Letter Queues (DLQs) to Handle Failures

If a message (e.g., Payment event) fails multiple times, move it to a Dead Letter Queue for later processing.

A Dead Letter Queue (DLQ) is a specialized queue where messages that fail multiple processing attempts are sent. This helps prevent message loss and allows for troubleshooting, debugging, and retrying messages later.

How a DLQ Works

Message Processing Attempt
- A message (e.g., a Payment Event) is picked up from the main queue and processed.
Failure Handling & Retry
- If the processing fails (e.g., due to a database issue, API failure, or a bug), the message is retried a predefined number of times.
- This is typically configured as Max Retry Attempts (e.g., 3 attempts).
Message Moves to DLQ
- If the message still fails after reaching the retry limit, it is moved to the DLQ instead of being discarded.
- The DLQ is separate from the main queue and holds these "failed" messages for further action.
Monitoring & Processing DLQ Messages
- Messages in the DLQ can be inspected, fixed, or manually retried later.
- Some systems have automated retries with exponential backoff
  
  RabbitMQ DLQ Configuration: x-dead-letter-exchange: "dlx.orders" x-dead-letter-routing-key: "orders.failed"

Thursday, May 1, 2025

Top scenario based microservices interview questions

1. Implement Circuit Breaker Pattern (Prevent System Overload)

2. Use Retry Mechanism for Temporary Failures

3. Set Timeouts to Avoid Blocking Requests

4. Implement Fallback Mechanisms

Example: Weather App with Celsius

5. Use Asynchronous Processing for Non-Critical Requests

Conclusion

. Use the Saga Pattern (Recommended)

1. Orchestration

Steps in Orchestration:

Example:

2. Choreography

Steps in Choreography:

Example:

Summary:

Real-World Example:

In the system:

Why It’s Useful:

Example in Code:

Pros and Cons:

In Summary:

5. Use Dead Letter Queues (DLQs) to Handle Failures

How a DLQ Works

3. API Gateway and Security

1. Security - JWT Authentication

Dependencies (pom.xml):

2. Rate Limiting

How It Works Behind the Scenes

A user sends API requests.Redis keeps track of how many requests they have made.If they exceed 10 per second, new requests are throttled (delayed) or blocked.This ensures the system is not overloaded. Make sure you have Redis set up and Spring Data Redis dependency included.

Add Redis Dependency in pom.xml: <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-gateway</artifactId> </dependency>

3. Request Validation

Example Request Validation:

public class UserRequest {

@NotNull

@Size(min = 2, max = 30)

private String name;

@NotNull

@Email

private String email;

// Getters and setters

}

@RestController

public class UserController {

@PostMapping("/users")

public ResponseEntity<String> createUser(@Valid @RequestBody UserRequest userRequest, BindingResult result) {

if (result.hasErrors()) {

return ResponseEntity.badRequest().body("Invalid request parameters.");

}

// Proceed with processing

return ResponseEntity.ok("User created successfully!");

}

4. Complete Gateway Setup

You can configure Spring Cloud Gateway with a combination of filters for authentication, rate-limiting, and request validation.

application.yml for Gateway:

Custom Authentication Filter:

@Component

public class JwtAuthenticationFilter implements GlobalFilter {

@Override

public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {

String token = exchange.getRequest().getHeaders().getFirst(HttpHeaders.AUTHORIZATION);

if (token != null && token.startsWith("Bearer ")) {

// Validate token logic

}

return chain.filter(exchange);

}

Conclusion

1. Mutual TLS (mTLS) for Service-to-Service Authentication

is a mechanism in which both the client and the server authenticate each other using certificates. It ensures that only authorized services can communicate with each other, providing encryption and identity verification.

How mTLS Works in a Web App?

Steps:

Example: Enabling mTLS in Spring Boot

Step 1: Generate Certificates

Both services need their own certificates using OpenSSL:openssl req -new -x509 -days 365 -keyout serviceA.key -out serviceA.crt openssl req -new -x509 -days 365 -keyout serviceB.key -out serviceB.crt

Step 2: Configure mTLS in Spring Boot (application.yml)

server: port: 8443 ssl: enabled: true key-store: classpath:serviceA.p12 key-store-password: password trust-store: classpath:serviceB.p12 trust-store-password: password client-auth: NEED # Requires both services to authenticate

2. OAuth 2.0 / JWT for Service Authentication

Another approach is to use

How it works:

Dependencies (`pom.xml`):

A user sends API requests.
Redis keeps track of how many requests they have made.
If they exceed 10 per second, new requests are throttled (delayed) or blocked.
This ensures the system is not overloaded.

Make sure you have Redis set up and Spring Data Redis dependency included.

Add Redis Dependency in `pom.xml`: <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-gateway</artifactId> </dependency>

`application.yml` for Gateway:

Both services need their own certificates using OpenSSL:
openssl req -new -x509 -days 365 -keyout serviceA.key -out serviceA.crt openssl req -new -x509 -days 365 -keyout serviceB.key -out serviceB.crt

Step 2: Configure mTLS in Spring Boot (`application.yml`)

🔹 A single request comes to the API Gateway. 🔹 The API Gateway calls multiple services (like User Service, Order Service, Payment Service). 🔹 It merges the results and sends one response to the user.
Example:

🔹 A single request comes to the API Gateway. 🔹 The API Gateway calls multiple services (like User Service, Order Service, Payment Service). 🔹 It merges the results and sends one response to the user.
Example:

Network Latency: This approach may incur some performance overhead as multiple calls to different services need to be made.
Error Handling: You need to handle errors properly in case one of the services is unavailable.