J.P Morgan 2nd Tech Round EXPOSED! Real JAVA Backend Interview Experience!

In this video , we are going to discuss 2nd Tech Round for J.P Morgan Question 1: Service Dependency Failure Scenario: Suppose Service A depends on Service B and Service C. If Service B is down but C is working fine, how will you ensure that Service A continues to function and responds gracefully? Ans: In microservices, services often rely on other services to perform their operations. If Service A makes HTTP or RPC calls to both B and C, and B becomes unavailable, without any handling logic: • Requests to A could fail completely. • Users may experience timeouts or 500 errors. • The entire system could become unreliable or unavailable, even if only a single dependency is affected. Goals we can acheive 1. Ensure Service A remains responsive and stable. 2. Avoid cascading failures. 3. Provide degraded functionality when possible. 4. Monitor and recover when Service B is back. Step 1: Circuit Breaker PatternPrevents Service A from calling Service B repeatedly if it’s known to be down.Tools:  Resilience4j (lightweight & modern)Example with Reslience4j Step 2: Timeouts and Retries Ensure that Service A does not wait indefinitely for a response from Service B. Set connection timeouts and read timeouts. Implement exponential backoff with retry logic (with limits). Step 3: Graceful Degradation / Fallback Response Provide partial data or cached data from Service B if real-time call fails. Real-Life Example: If Service B gives user preferences, fallback could return default preferences so that Service A can still render the UI. Step 4: Service B Call Isolation Use thread pool or bulkhead pattern to isolate external service calls. Why?: If Service B hangs, it should not exhaust Service A’s main thread pool. Step 5: Monitoring and Alerting Use Prometheus, Grafana to track: Service B failure rate Circuit Breaker state (OPEN, HALF_OPEN, CLOSED) Latency and retries Fallback count Step 6: Decouple via Asynchronous Communication (Optional) If B can be asynchronous, use a message queue (Kafka, RabbitMQ): Service A publishes event Service B processes independently Service A reads result later or shows “processing” Component Purpose Circuit Breaker Stop flooding failing service Fallback Provide default/cached data Timeout & Retry Limit blocking and retry intelligently Bulkhead Pattern Isolate failures to protect other services Monitoring Track and alert failures Async Handling Optional decoupling for resilience Q2. High Latency in a Microservice Under Load Scenario:Your microservice is facing high latency under load.How do you identify the root cause and resolve the issue? Step 1: Reproduce and Observe the ProblemCheck logs for slow requests. Use load testing tools: Apache JMeter k6 Gatling Validate if the issue is due to: High CPU usage Memory pressure Thread pool exhaustion External dependency slowness (e.g., database, REST calls) Step 2: Enable Distributed TracingTrack each request across the system to pinpoint the latency source. Tools: Zipkin OpenTelemetry New Relic / Datadog What to look for: Breakdown of time spent in: Internal processing DB calls External HTTP/gRPC calls Where the longest spans occur Request Timeline: Received: 0 ms Auth Service: 15 ms DB Query: 230 ms Bottleneck Response Ready: 270 ms Step 3: Profile MetricsUse Prometheus + Grafana or Micrometer to capture: Metric Insight CPU / Memory usage Resource bottleneck Request per second (RPS) Current traffic load Latency percentiles (P95) How bad the latency is Thread pool queue size Starvation or deadlocks GC pauses JVM tuning issue Q3. If Database is slow –How you will fix it? Ans: Scenario : Long-running queries, high DB CPU, slow joins. Fixes: Add indexing, optimize queries. Use read replicas to distribute load. Implement caching (e.g., Redis) for frequent queries. Enable connection pooling (e.g., HikariCP). Use connection pool monitoring: check for timeouts or pool exhaustion. Q4. If External API is slow –How you will fix it? Ans: Scenario : Third-party or internal dependent service is responding slowly Fixes: Add timeout, retry, and circuit breaker. Use fallbacks or cached responses. Move to asynchronous processing (e.g., message queues like Kafka, RabbitMQ). Q5. If Thread Pool Exhaustion –How you will fix it? Ans: Scenario : All threads are busy; requests wait in a queue Fixes: - Tune thread pool size: In Java, use Executors.newFixedThreadPool(...) Use Reactor schedulers for reactive systems - Offload heavy operations to separate thread pools - Prefer non-blocking I/O (Spring WebFlux, Project Reactor) Q6. Securing Microservice Communication? Ans: Scenario : You have multiple microservices communicating internally.How do you secure the communication between them?: Step 1: Secure Transport with TLS / mTLS What is TLS? Encrypts the communication channel to prevent interception. Used in HTTPS (unidirectional TLS). #javainterviewquestions #java #backend