Microservices & APIs Interview Prep

REST API interview questions are core to every Java backend role — RESTful constraints, HTTP semantics and status codes, idempotency, request/response design, error handling, validation, pagination (cursor vs offset), HATEOAS, API versioning, OpenAPI/Swagger, HTTP clients (RestTemplate, WebClient, Feign), HTTP caching (ETag, Cache-Control), and Spring MVC controller fundamentals. For GraphQL-specific questions see the dedicated GraphQL page; for gRPC see the gRPC page.

REST = a set of constraints over HTTP — not the sole way to design APIs, but the senior interview default.

• Resources are nouns; verbs map to HTTP methods (GET / POST / PUT / PATCH / DELETE).
• Statelessness — every request stands alone.
• Idempotency — GET / PUT / DELETE should be safe to retry.
• Status codes — 2xx success, 3xx redirect, 4xx client, 5xx server; pick the most specific.
• Pagination — cursor over offset for stable paging.

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

• Api design — 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.
• Error handling — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Hateoas — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Http caching and compression — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Openapi and swagger — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Request and response handling — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Rest client and feign — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Rest fundamentals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Spring mvc controllers — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Versioning — 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.

• PUT vs PATCH — full replace vs partial; PATCH is typically merge-patch.
• HATEOAS — pure REST principle; in practice, OpenAPI replaced it for most teams.
• Idempotency keys — the modern way to deduplicate retries on POST.
• Versioning — URL path (most common) > header > query; commit to one.
• Error model — RFC 7807 problem+json or a documented envelope; be consistent.

"I'd model `/resources` as plural nouns, use for safe retries, page via cursor, document the schema with OpenAPI, and standardise errors with problem+json. Versioning lives in the URL path because ."

GraphQL interview questions test whether you understand the query-language alternative to REST — schema design (types, queries, mutations, subscriptions), resolvers, the N+1 problem and DataLoader, schema federation, persisted queries, error handling, security (depth limiting, query cost analysis), and the integration patterns with Spring for GraphQL. Expect the interviewer to compare GraphQL to REST and ask when you would choose each — that question is covered in depth here.

GraphQL = single endpoint + typed schema + client-driven queries.

• Resolvers map fields to data; the resolver tree is the call graph.
• DataLoader batches + caches per-request — fixes the N+1.
• Mutations are RPC-flavoured; subscriptions are WebSocket / SSE.
• Federation stitches multiple subgraphs into one API.
• Schema-first vs code-first — pick a side and stick to it.

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

• Graphql fundamentals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.

• Over-fetching is REST's problem; GraphQL's problem is over-asking.
• Persisted queries — security + caching + bandwidth.
• Auth — at the resolver level; not in middleware.
• Depth / cost limits — prevent malicious deep queries.
• Errors — partial-success model; clients must handle field-level errors.

"I'd model the schema around the read needs of the client, batch nested fetches with DataLoader, persist queries for cacheability, enforce depth + cost limits, and authorise inside resolvers so each field is independently checked."

gRPC interview questions cover the high-performance RPC framework increasingly common in microservice interviews — Protocol Buffers (proto3), the four service types (unary, server-streaming, client-streaming, bidi), interceptors, deadlines and cancellation, load balancing, gRPC vs REST vs messaging trade-offs, and the gRPC + Spring Boot integration patterns. This page is the one to use for any role that mentions internal service-to-service RPC at scale.

gRPC = HTTP/2 + Protocol Buffers + 4 RPC styles (unary / server-stream / client-stream / bidi).

• Codegen from .proto keeps client and server contract-locked.
• Deadlines propagate through the call chain — set them.
• Interceptors for auth, logging, metrics — both client and server side.
• Load-balancing — client-side (look-aside) common in service meshes.

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

• Grpc fundamentals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.

• Protobuf field numbers are immutable — never reuse, even after delete.
• Backwards compatibility — add new optional fields, never repurpose.
• Browser support — gRPC-Web is required; pure gRPC won't work from a browser.
• Error codes — gRPC status codes ≠ HTTP; learn the mapping.
• vs REST — pick gRPC for internal service-to-service, REST for external APIs.

"I'd define the contract in proto, version fields by adding new tags only, set deadlines per call, route through a service mesh for client-side LB, and reserve REST for the external edge where browser + caching matter."

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."

RabbitMQ interview questions cover the AMQP-based broker still common in finance, telco and any Java backend that needs flexible routing — exchange types (direct, fanout, topic, headers), bindings and routing keys, queue durability and message persistence, dead-letter exchanges and DLQ patterns, prefetch and consumer ack strategies, publisher confirms, clustering and quorum queues, and the Spring AMQP integration patterns. Use this page when the role specifies RabbitMQ over Kafka.

RabbitMQ = AMQP broker with rich routing.

• Exchanges route — direct / topic / fanout / headers.
• Queues durable + persistent + manual ack ⇒ at-least-once.
• Quorum queues (3.8+) replace mirrored queues — Raft-replicated.
• Prefetch + manual ack tunes throughput vs fairness.
• DLX (dead-letter exchange) catches poison messages.

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

• Rabbitmq fundamentals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.

• Manual ack — no ack ⇒ redelivery on consumer crash; classic interview trap.
• Publisher confirms — at-least-once on the publish side.
• Quorum vs classic — Raft vs single-master; pick quorum for new clusters.
• Topic exchange wildcards — * one word, # zero+ words.
• Backpressure — close to publish-side at the connection level when consumers fall behind.

"I'd use a topic exchange routed on `.`, durable + quorum queues, manual ack with prefetch tuned, publisher confirms on the producer, and a DLX bound to a parking queue for ops to inspect."