Company Round Scenarios

Tests whether you know how to use thread dumps and profilers to find a runaway loop or lock contention that logs alone won't show.

Tests whether you know this is the classic signature of a memory leak — objects still reachable that shouldn't be — and how heap dump analysis finds it.

Tests whether you know GC pause time depends on more than heap occupancy — fragmentation, GC algorithm choice, and region sizing matter too.

Tests whether you know slow leaks (unbounded caches, listener leaks, ThreadLocal misuse) take time to surface and aren't tied to a deploy.

Tests whether you know low CPU with high queuing usually points to threads blocked waiting on I/O, not a CPU bottleneck.

Tests whether you know these aren't synonyms — coupling, communication protocols, and team ownership all differ.

Tests whether you know DDD is the actual discipline behind 'good service boundaries,' not just a buzzword to drop.

Tests whether you know config, backing services, and stateless processes matter more than the rest for this architecture style.

Tests whether you can push back on premature decomposition instead of defaulting to microservices as automatically 'better.'

Tests whether you know blocking I/O versus a reactive Netty core is the real reason Gateway replaced Zuul 1.

Tests whether you connect the choice to blocking vs non-blocking behavior, not just API ergonomics.

Tests whether you know how to design idempotent processing instead of trying to guarantee exactly-once delivery, which most brokers don't offer by default.

Tests whether you know how an idempotency key on the client request prevents duplicate processing server-side.

Tests whether you know to separate transport-layer success from application-layer correctness — caching, replication lag, or stale reads are common culprits.

Tests whether you can actually design an idempotency-key mechanism end to end, not just name the pattern.

Tests whether you know binary Protobuf and HTTP/2 streaming pay off for low-latency internal service calls, not public APIs.

Tests whether you know cursor pagination stays correct even as rows are inserted or deleted mid-scroll.

Tests whether you know consumer-driven contracts let services deploy independently without a shared integration environment.

Tests whether you know circuit breakers, timeouts, and bulkheads are what actually stop one slow dependency from taking down everything downstream.

Tests whether you know how failure-rate threshold, sliding window size, and slow-call-duration settings actually control breaker sensitivity.

Tests whether you know how a propagated correlation/trace ID and distributed tracing (Zipkin, Jaeger) turn this into a solvable problem.

Tests whether you know modern Kafka has real tools to avoid the classic stop-the-world rebalance pain.

Tests whether you know exact-match routing versus wildcard-pattern routing versus broadcast, and when each fits.

Tests whether you know a persisted 'already processed' record is what actually makes a handler safe to call twice.

Tests whether you know this is a cache avalanche/stampede, and can name real mitigations like jittered TTLs or request coalescing.

Tests whether you know a hot key can bottleneck a cluster regardless of total capacity, and how local caching or key splitting helps.

Tests whether you know why a distributed counter (like Redis-backed) is needed instead of an in-memory counter on each instance.

Tests whether you know to check for connection leaks (unclosed connections), a misconfigured pool size, or a sudden spike in concurrent traffic post-deploy.

Tests whether you know how to spot N+1 via SQL logging or an APM tool, and fix it with fetch joins or EntityGraph.

Tests whether you know low CPU with rising lag usually points to a slow downstream call inside the consumer, not a compute-bound processing loop.

Tests whether you know to route unprocessable messages to a dead-letter topic instead of blocking the whole partition indefinitely.

Tests whether you know rebalances can reassign a partition before an offset commit lands, and why consumer-side idempotency is the real fix.

Tests whether you know to check load balancer deregistration delay, DNS caching, and connection draining settings.

Tests whether you know to check rollout status, readiness probes, and whether the deployment is stuck on a failing pod.

Tests whether you know about @RefreshScope and Spring Cloud Bus for propagating config changes to live instances.

Tests whether you know to check for missing dependency caching, network-bound repository access, and parallel build configuration in CI.

Tests whether you know a naive lock can still let a stale, slow process act after losing the lock — fencing tokens close that gap.

Tests whether you know there's an actual formula behind pool sizing, not just picking a round number and hoping.

Tests whether you know the isolation-strength versus operational-complexity tradeoff between the two approaches.

Tests whether you know CDC lets you build a denormalized read store without touching the write-side service's code at all.

Tests whether you know dual credentials and a gradual rollover are what make rotation invisible to running traffic.

Tests whether you know real JWT vulnerabilities beyond 'just check the signature.'

Tests whether you know to allowlist domains and specifically block internal metadata IP ranges like 169.254.x.x.

Tests whether you know Istio or Linkerd can automate certificate exchange and rotation instead of hand-rolling it per service.

Tests whether you know Broken Object Level Authorization and Excessive Data Exposure are the two most common real-world findings.

Tests whether you know keys should be hashed at rest, prefixed for fast lookup, and support rotation and per-key rate limiting.

Tests whether you know to check gateway-level timeouts, connection pool limits, and TLS/handshake issues that never reach the backend's own logs.

Tests whether you know to suspect load-balanced instances serving stale data, race conditions, or a caching layer with inconsistent state.

Tests whether you know to check the execution plan, missing indexes, and whether staging data volume was too small to expose the problem.

Tests whether you know to check container logs, exit codes, resource limits (OOMKilled), and health check configuration.

Tests whether you know thread pool isolation gives stronger isolation at higher resource cost than semaphore-based limiting.

Tests whether you know jitter is what prevents every client from retrying in lockstep and re-creating the thundering herd.

Tests whether you know the point is deliberately injecting failure to verify circuit breakers and fallbacks actually work, not just exist.

Tests whether you know one throws immediately (open circuit) while the other silently returns a default value — different failure philosophies.

Tests whether you know RED is request-oriented (Rate/Errors/Duration) while USE is resource-oriented (Utilization/Saturation/Errors).

Tests whether you know OTEL is the vendor-neutral standard that replaced Sleuth starting in Spring Boot 3.

Tests whether you know multi-window burn-rate alerting catches real problems faster than a single static threshold alert.

Tests whether you know async profilers, JFR, and sampled distributed traces are the real tools for this exact situation.

Tests whether you know which workload shape (stateless, ordered/stable identity, one-per-node) each object type is built for.

Tests whether you know KEDA scales on external event sources (like Kafka lag) that HPA's CPU/memory metrics can't see.

Tests whether you know a JVM's real memory footprint is bigger than just -Xmx, and getting this wrong causes OOMKilled or CPU throttling.

Tests whether you know PodDisruptionBudget, readiness gates, and backward-compatible DB migrations all need to align.

Tests whether you know how eliminating the thread-per-request ceiling changes what's actually achievable at scale.

Tests whether you know limitRate() and the onBackpressure operators exist specifically to protect a slow consumer.

Tests whether you know GraalVM native images and CRaC are the real levers, not just 'use a smaller JAR.'

Tests whether you know unit tests should dominate by volume, with fewer integration and even fewer end-to-end tests above them.

Tests whether you know spinning up a real containerized database beats mocking the persistence layer for genuine confidence.

Tests whether you know high coverage can still hide weak assertions, and mutation testing is what actually catches that.

Tests whether you know an immutable, append-only store with correlation IDs is what makes an audit trail actually trustworthy.

Tests whether you know this needs a strangler-fig approach with an anti-corruption layer, not a risky one-shot cutover.

Tests whether you know active-active needs conflict resolution while active-passive trades that complexity for slower failover.

Tests whether you know to add characterization tests and extract leaf domains first, rather than attempting a risky big-bang rewrite.

Tests whether you can combine a Git-backed config server, environment overlays, and secret management into one coherent design.

A real Flipkart interview scenario testing whether you can design atomic inventory control under extreme concurrent load.

A real Walmart interview scenario testing whether you can combine four separate fixes into one coherent architecture.

A real Walmart interview scenario testing whether you've thought through what happens when your own fix becomes the new bottleneck.

A real Walmart interview deep-dive testing whether you can distinguish three commonly-confused caching failure modes and fix each correctly.

Tests whether you connect the fixed time to a scheduled job or resource leak, and know the JVM-metrics-then-heap-dump investigation order.

A real PayPal coding-round question testing whether you can recognize and implement a budget-constrained optimization pattern.

A real Google interview question testing whether you can trade off between recomputation and storage under a tight space constraint.

A real Google data-structure-design round testing whether you know bucket sort variations solve this cleanly.

A real PhonePe interview question testing whether you can design for financial correctness under partial failure.

A real Atlassian interview question testing whether you can model a highly configurable, permission-heavy domain at scale.

A real Accenture interview question that looks simple but tests genuine understanding of hashing internals.

One of the most commonly asked service-based-company questions — tests whether you understand the proxy mechanism, not just the annotation's existence.

Tests whether you can go beyond 'one is thread-safe' into the actual locking/CAS mechanism that makes it so.