⚡ Fault Tolerance – Detailed Answers

1. If Service A → B → C and B fails, how do you handle it?

Picture this chain like a relay:

A → B → C

If B collapses, you don’t want A to panic and bring down the whole system.

---

✅ Strategies I Use

🔹 1. Circuit Breaker

• Stop calling B when it’s failing
• Return fallback response instead

👉 Prevents cascading failure

---

🔹 2. Retry Mechanism

• Retry request to B with limits

👉 Use for temporary failures only

---

🔹 3. Fallback Logic

• Provide default or cached response

👉 Example:

• Show “Service unavailable”
• Or return last known data

---

🔹 4. Asynchronous Handling

• Use queue instead of direct call

👉 A sends message → B processes later

---

🔹 5. Timeout Control

• Don’t wait forever for B

👉 Fail fast, recover fast

---

🎯 Interview Answer

“If B fails, I use circuit breaker to prevent repeated failures, apply retries for transient issues, define fallback responses, and where possible shift to asynchronous communication to decouple services.”

---

2. What is Circuit Breaker?

Circuit Breaker is like an automatic fuse ⚡ in an electrical system.

🔹 Definition

A pattern that:

• Detects failures
• Stops calls to a failing service
• Allows recovery after some time

---

🔁 States of Circuit Breaker

1. Closed (Normal)

   • Calls go through

2. Open (Failure Mode)

   • Calls blocked
   • Immediate fallback

3. Half-Open (Testing Mode)

   • Allow limited requests
   • If success → close
   • If fail → open again

---

🎯 Key Benefit

👉 Prevents cascading failures and reduces system load

---

3. How do you implement Circuit Breaker?

In Spring Boot, the go-to choice is:

👉 Resilience4j

---

🔹 Basic Example

@CircuitBreaker(name = "serviceB", fallbackMethod = "fallbackMethod")
public String callServiceB() {
    return restTemplate.getForObject("http://service-b/api", String.class);
}

public String fallbackMethod(Exception ex) {
    return "Fallback response";
}

---

🔹 Configuration (application.yml)

resilience4j:
  circuitbreaker:
    instances:
      serviceB:
        failureRateThreshold: 50
        waitDurationInOpenState: 10s
        slidingWindowSize: 10

---

🔹 Bonus Features

• Retry
• Rate limiter
• Bulkhead (limit concurrent calls)

---

🎯 Interview Tip

“I use Resilience4j with Spring Boot annotations for circuit breaker, combined with retry and fallback strategies.”

---

4. How do you handle exceptions in Spring Boot?

Exception handling is like air traffic control ✈️ You don’t want chaos when things go wrong.

---

🔹 Approaches

✅ 1. Global Exception Handling (Best Practice)

Use:

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(Exception.class)
    public ResponseEntity<String> handleException(Exception ex) {
        return new ResponseEntity<>("Something went wrong", HttpStatus.INTERNAL_SERVER_ERROR);
    }
}

---

✅ 2. Custom Exceptions

public class ResourceNotFoundException extends RuntimeException {
    public ResourceNotFoundException(String msg) {
        super(msg);
    }
}

---

✅ 3. Structured Error Response

{
  "timestamp": "2026-04-22",
  "message": "Resource not found",
  "status": 404
}

---

5. Do you use try-catch or global exception handling?

This is a classic trap question 🎯

---

❌ Avoid Overusing try-catch

• Makes code messy
• Hard to maintain

---

✅ Best Practice

🔹 Use Global Exception Handling

• Centralized
• Clean code
• Consistent responses

🔹 Use try-catch Only When:

• You can recover immediately
• You want custom handling at that point

👉 Example:

• Parsing
• External API call with fallback

---

🎯 Perfect Interview Answer

“I prefer global exception handling using @RestControllerAdvice for consistency and cleaner code. I use try-catch only in specific scenarios where I can handle or recover from the exception locally.”

---

🚀 Final Cheat Sheet

• B fails → use Circuit Breaker + Retry + Fallback
• Circuit Breaker → prevents cascading failure
• Tool → Resilience4j
• Exception handling → Global handler preferred
• try-catch → only for specific recovery cases

---