Distributed Systems Interview Prep

System design interview questions are the differentiator for senior and staff Java backend roles — capacity estimation, the building blocks (load balancers, caches, queues, databases, CDNs), data partitioning, replication and consistency, rate limiting, idempotency at scale, designing for high availability, and the trade-offs that show up in every system-design round (latency vs throughput, consistency vs availability). This page covers the fundamentals; for full case studies (URL shortener, Twitter feed, distributed cache) see the System Design Problems page.

Always answer in 5 steps — never skip a step.

1. 1
   Requirements (functional + non-functional + scale).
2. 2
   Capacity (QPS, storage, bandwidth).
3. 3
   API + data model.
4. 4
   High-level design (boxes + arrows).
5. 5
   Deep dive on the bottleneck the interviewer cares about.

Cite CAP + PACELC when consistency is on the line.

The interview surface for this module breaks into these focus areas:

• Caching at scale — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Cap theorem — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Capacity planning — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Comparisons — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Database design at scale — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Design fundamentals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Event driven design — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• High availability — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Load balancing — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Microservices design — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scalability — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scenario-based — applied questions tying multiple topics together. Drill these last, after the fundamentals are sharp.

• Latency vs throughput — they trade against each other; cite p99 not avg.
• Sharding is a reorg, not an optimisation — earn it.
• Cache before sharding; read replicas before sharding.
• Idempotency at scale — keys + TTL + DB unique constraint.
• Back-of-envelope numbers — 1 GB/s ≈ 8 Gbps; 1 ms = 1 disk seek; 100 µs = 1 SSD read.

"At I'd start with a load balancer in front of stateless app servers, a primary DB with read replicas, Redis for hot reads, Kafka for async work. The bottleneck will be — the deep dive lives there."

Microservices interview questions test architectural judgement, not just framework knowledge — service decomposition, API gateway patterns, service discovery, client- vs server-side load balancing, circuit breaker / retry / bulkhead / time limiter (Resilience4j), saga and outbox patterns, distributed tracing (correlation IDs, OpenTelemetry, Zipkin), config management (Spring Cloud Config), service mesh (sidecars, Istio basics), and the migration patterns from monolith to microservices (strangler fig). Pair this with the REST API and Messaging/Kafka pages for the full microservices interview surface.

Microservices = independent deployability + bounded contexts, paid for in operational complexity.

• Service boundary = bounded context (DDD); never split by tech layer.
• Sync (REST / gRPC) vs Async (Kafka / SNS) — pick by coupling tolerance.
• Resilience — retry, circuit-breaker, bulkhead, timeout (Resilience4j).
• Discovery — server-side (LB) vs client-side (Eureka).
• Tracing — OpenTelemetry; correlation IDs are non-negotiable.

The interview surface for this module breaks into these focus areas:

• Api gateway — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Circuit breaker — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Communication patterns — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Comparisons — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Config management — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Contract testing — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Distributed tracing — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Feign client — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Fundamentals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Load balancing — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Migration strategies — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Resilience patterns — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Saga pattern — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Service design — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Service discovery — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Service mesh — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scenario-based — applied questions tying multiple topics together. Drill these last, after the fundamentals are sharp.

• Distributed transactions — don't; use saga (orchestration vs choreography) and outbox.
• Strangler-fig — the only sane monolith → microservices migration pattern.
• Service mesh — sidecars (Istio / Linkerd) move resilience out of code, at infra cost.
• Contract testing — Pact / Spring Cloud Contract — prevents the cross-service break.
• Cost — every new service is a new pager; senior answer always weighs ops cost.

"I'd start with a modular monolith, split out the service when appears, communicate sync via and async via with the outbox pattern, wrap calls in Resilience4j circuit-breakers, and stand up tracing on day one."

Kafka and event-driven architecture interview questions cover the messaging system that powers most modern Java backends — Kafka architecture (brokers, topics, partitions, consumer groups, ISR), delivery semantics (at-most-once, at-least-once, exactly-once), idempotent consumers, the outbox pattern, schema evolution, Kafka Streams vs Flink vs Spark Streaming, the saga pattern with choreography, CQRS and event sourcing, and Spring Kafka / Spring Cloud Stream. For RabbitMQ-specific questions (exchange types, routing, DLX), see the dedicated RabbitMQ page.

Three big questions for any event system:

1. 1
   Delivery semantics — at-most / at-least / exactly-once.
2. 2
   Ordering — per-partition (Kafka) vs per-queue (RabbitMQ).
3. 3
   Durability — acks, replication factor, ISR, fsync vs not.

Kafka = log; RabbitMQ = router; SQS = simple queue. Pick by fit-for-purpose, not hype.

The interview surface for this module breaks into these focus areas:

• Comparisons — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Cqrs — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Event sourcing — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Kafka architecture — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Kafka patterns — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Message guarantees — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Messaging fundamentals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Spring kafka — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Stream processing — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Webhooks — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scenario-based — applied questions tying multiple topics together. Drill these last, after the fundamentals are sharp.

• Exactly-once is delivery + processing; both must be idempotent.
• Outbox pattern — write event in same DB tx as state change, relay to broker.
• CQRS — read/write split; events update a denormalised read model.
• Kafka partition count is forever — picking it too low costs a topic re-create.
• Consumer rebalances — the silent latency spike during deploys.

"I'd publish events via the outbox so the DB write and broker write are atomic, partition the topic by for ordering, run consumers as idempotent (`UPSERT` keyed by event id), and watch for consumer-lag + rebalance frequency in observability."