Spring Boot Performance, Scaling & Resilience — Interview Questions

How to use this lesson

Performance questions are really method questions. Interviewers want to hear that you measure before changing anything, find the bottleneck, fix that, and verify. A list of buzzwords ("add caching, use WebFlux") without a diagnosis is the answer they're trying to filter out.

Q1. Your Spring Boot app slows down under high load. How do you find and fix the problem?

Short answer: Follow a loop: observe → reproduce → locate → fix → verify.

1. Observe with metrics, using Micrometer (with Prometheus/Grafana, or any other backend). Look at p95/p99 latency per endpoint, error rates, and saturation: Tomcat busy threads, HikariCP active and pending connections, GC pauses, CPU. Use distributed traces to see where the time goes.
2. Reproduce with a load test (Gatling, k6, JMeter) against a production-like environment.
3. Locate the cause with a profiler (async-profiler, JFR), thread dumps (threads BLOCKED on a lock, or WAITING for connections?) and slow-query logs, plus EXPLAIN.
4. Fix the actual bottleneck, then re-run the same load test to confirm.

Key points to cover:

• The usual culprits:
  • N+1 queries, and missing indexes.
  • An exhausted connection pool.
  • Slow downstream calls without timeouts.
  • Lock contention.
  • Excessive logging or serialisation.
  • GC pressure from large allocations.

Learn it in depth → Metrics & Monitoring

Q2. Performance issues under high load: describe your first 30 minutes. (A common rephrasing)

Short answer:

• Minute 0–5: check the dashboards. Did latency rise for all endpoints (a shared resource: database, pool, GC, CPU) or one (that endpoint's code or dependency)? Was there a deployment or configuration change?
• Minute 5–15: take thread dumps and pool metrics. Many threads waiting in HikariPool.getConnection means the database or pool is the bottleneck. Many waiting on a RestClient call means a slow dependency.
• Minute 15–30: mitigate first (roll back, scale out, shed load, or open the circuit to a failing dependency), then find the root cause offline, with a profiler and load test.

Q3. What strategies would you use to optimise a Spring Boot application's performance?

Short answer: Group them by where the time goes:

Common trap: "switch to WebFlux". Reactive helps only with huge numbers of concurrent, I/O-bound connections, with a fully non-blocking stack. It adds complexity, and it doesn't speed up slow SQL. Virtual threads often deliver the same scalability with plain blocking code.

Q4. What strategies would you use to optimise performance? (Asked again: which would you try first?)

Short answer: The cheapest, highest-impact fixes first:

1. Query fixes (N+1, indexes). These are often 10–100× wins.
2. Timeouts and pool sizing, which stop pile-ups.
3. Caching hot reads.
4. Moving non-critical work off the request path (events or queues for emails and analytics).

Hardware scaling and architectural changes come after you've removed obvious waste. Each change should be justified by a measurement.

Q5. Describe a Spring Boot project where you significantly improved performance.

Short answer (a model story; use your own numbers): "Order-history requests hit p99 of 4 s at peak. Tracing showed about 300 SQL queries per request, an N+1 on order lines and products. I replaced it with a fetch-join query plus DTO projection, added a composite index on (customer_id, created_at), and switched to keyset pagination. We cached product details in Caffeine with a 10-minute TTL, and moved invoice-PDF generation to an async queue. The p99 dropped to 250 ms, and database CPU fell 60%. We added a query-count assertion in integration tests, so the N+1 can't come back."

Key points to cover:

• A strong story has a baseline, a diagnosis tool, targeted fixes, a measured result, and a guardrail against regression.

Q6. How would you scale a Spring Boot application to handle high traffic?

Short answer:

• Make the app stateless: no in-memory sessions or local-only caches for correctness.
• Scale horizontally behind a load balancer.
• Autoscale: Kubernetes HPA on CPU, or custom metrics such as requests per second or queue lag.
• Protect the data tier: connection limits (instances × pool size must stay within the database's max_connections), read replicas, caching, and eventually partitioning.
• Move work to async queues.
• Use an API gateway for rate limiting.
• Use a CDN for static and cacheable content.
• Split services only where a component has distinct scaling needs.

Learn it in depth → Horizontal vs Vertical Scaling

Q7. How would you scale for high traffic? (Follow-up: what breaks first when you add instances?)

Short answer: Usually the database. Twenty instances with a pool of 20 connections each means 400 connections, which can exceed database limits or thrash it. Other things that break:

• In-memory state: sessions, caches, and scheduled jobs that now run on every instance (use ShedLock or a leader election).
• Rate limits at downstream providers.
• Non-idempotent consumers under redelivery.

Plan for these before adding instances. For example, use a connection proxy (PgBouncer, or RDS Proxy), and size the pools deliberately.

Q8. How is session management configured in distributed systems?

Short answer: Prefer stateless authentication (JWT or opaque OAuth2 tokens validated by each service), so there's no session to share. When you do need server-side sessions (server-rendered apps, or login flows), use Spring Session. It transparently stores HttpSession data in Redis (or JDBC or Hazelcast), so any instance can serve any request.

spring:
  session:
    redis:
      namespace: shop:sessions
    timeout: 30m
  data:
    redis:
      host: redis.internal

Key points to cover:

• Sticky sessions are a fragile alternative. Sessions are lost when the instance dies, and the load becomes uneven.
• Store little in the session (IDs, not object graphs). Secure the cookie (HttpOnly, Secure, SameSite), and rotate the session ID at login.

Q9. How can Spring Boot applications be made more resilient to failures in a microservices architecture?

Short answer: Assume every dependency will fail, and contain the damage with Resilience4j (Spring Cloud Circuit Breaker):

• Timeouts on every remote call: HTTP client connect and read timeouts, plus TimeLimiter.
• Retries with exponential backoff and jitter, for idempotent operations only.
• Circuit breakers, with fallbacks (cached data, defaults, degraded features).
• Bulkheads that cap the concurrent calls per dependency.
• Rate limiters, to protect yourself and downstream services.
• Async messaging, with DLQs and idempotent consumers.
• Health probes and graceful shutdown, so orchestrators route around sick instances.
• Observability, so failures are visible fast.

@CircuitBreaker(name = "recommendations", fallbackMethod = "popularProducts")
@TimeLimiter(name = "recommendations")
public CompletableFuture<List<Product>> recommendations(long userId) {
    return CompletableFuture.supplyAsync(() -> recoClient.forUser(userId), ioExecutor);
}
private CompletableFuture<List<Product>> popularProducts(long userId, Throwable t) {
    return CompletableFuture.completedFuture(cache.topSellers());           // degrade, don't fail the page
}

Learn it in depth → Circuit Breaker with Resilience4j

Follow-up questions this topic invites — and their answers

Q: How do you size the HikariCP pool? A: Start small. A common starting point is around (cores × 2) + effective spindles on the database side, often 10–20. Then tune with metrics (pending threads, connection wait time). Bigger pools often make performance worse, because the database spends its time context-switching.

Q: What does spring.threads.virtual.enabled=true change? A: On Java 21+, Tomcat request handling, @Async executors and some other executors run on virtual threads. Blocking I/O no longer ties up scarce platform threads, but the connection pools still limit how much concurrency actually reaches the database.

Q: How do you load-test realistically? A: Use production-like data volumes and traffic mixes, ramp up gradually, include think time, run long enough to reach a steady state (and catch leaks), and watch server-side metrics, not just client response times.

Q: What is load shedding? A: Rejecting some requests early (a 429 or 503), when the system is near saturation, so the requests you accept still succeed quickly. Examples: bounded queues, rate limiters, and adaptive concurrency limits.