Revise: Microservices & Microservice Patterns (5–8 Years Tier)

How to use this revision

This page condenses every question from the 5 to 8 Years course in these areas into a single line: the question, linked to its full answer, and the one-sentence answer you should be able to give instantly. Read down the list and answer each question aloud before reading the line. Wherever you hesitate, follow the link and revise the full answer — interviewers at your level expect these basics to be fluent, and they often open with them before going deeper.

Microservices at Scale

Monolith Migration, Communication & Spring Cloud — Interview Questions — open the lesson

• What are the disadvantages of microservices, and how do you address them? — Compared side by side in the full answer (table) — know each row.
• How would you call another service in a microservice architecture? — Synchronous request/response, when you need the answer now: REST over HTTP: Spring's RestClient, declarative HTTP interface clients (@HttpExchange), OpenFeign, or WebClient for reactive code; Asynchronous messaging, when the caller doesn't need an immediate result:…
• Explain a few microservices design patterns you know. — API Gateway: a single entry point for routing, authentication, rate limiting and aggregation. BFF is a gateway per client type; Service discovery: services register themselves, and clients look them up (Eureka, Consul, Kubernetes DNS); Circuit breaker: stop calling a failing…
• You're converting a monolith into microservices with Spring Boot. Describe the steps and the challenges. — Understand the domain first. Use domain-driven design (event storming) to find bounded contexts. Also look at change frequency, team ownership and scaling needs, to decide what's worth extracting; Modularise the monolith. Enforce module boundaries inside it (packages, Spring…
• How does Spring Cloud enhance microservices development with Spring Boot? — Spring Cloud provides ready-made implementations of the distributed-system patterns, configured the Boot way: Spring Cloud Gateway: routing, filters, rate limiting, token relay; Spring Cloud Config (or Consul/Vault configuration): centralised, versioned configuration with…
• You need an architecture with service-to-service communication. How would Spring Cloud help? — Discovery: each service registers (Eureka or Consul), or relies on Kubernetes DNS; Client-side load balancing: a @LoadBalanced RestClient.Builder resolves http://inventory-service, and balances across healthy instances; Declarative clients: HTTP interface clients or…
• What are the components of a typical Spring Cloud architecture? — Edge: Spring Cloud Gateway; Configuration: Spring Cloud Config Server (Git-backed), or Vault/Consul; Discovery: Eureka or Consul, or Kubernetes; Load balancing: Spring Cloud LoadBalancer; …
• Describe how you'd integrate Kafka with a Spring Boot application. — Add spring-kafka. Boot auto-configures KafkaTemplate, the consumer factories and the listener containers. @EnableKafka isn't needed with Boot; Configure spring.kafka.*: bootstrap servers; Produce with KafkaTemplate.send(topic, key, value). Choose the key for…
• What challenges have you faced developing or managing microservices, and how did you address them? — Use the STAR structure, with concrete examples. Typical, credible stories: Cascading failures: a slow payment provider exhausted the order service's threads. The fix: timeouts + circuit breaker + bulkhead, a fallback of "payment pending", and asynchronous confirmation; Data…
• What is service-oriented architecture (SOA)? — SOA is an architectural style in which applications are built from reusable, network-accessible services with well-defined contracts, often enterprise-wide.
• What are some challenges you've faced while working with microservices? (The team and technology angle) — Polyglot sprawl: too many languages and frameworks made on-call and upgrades hard. We standardised on a paved road (Spring Boot starters, shared libraries, templates), and allowed exceptions only with justification; Communication reliability: we moved non-critical paths to…

Data Consistency, Sagas & Kafka Messaging — Interview Questions — open the lesson

• How do you address data consistency across microservices? — Accept that there's no cross-service ACID transaction, and design for it: Each service owns its data, and changes it only with local ACID transactions; Sagas coordinate multi-service business processes. They're a sequence of local transactions, with compensating actions on…
• Database per service or a shared database: which do you prefer, and why? — Database per service (at least a schema per service with no cross-access) for real microservices: Loose coupling: schema changes are private; Independent deployment and scaling.; Fault isolation.; The right store for each job: Postgres for orders, Elasticsearch for search,…
• How do you handle distributed transactions in microservices? Explain the Saga pattern. — A saga breaks one business transaction into a series of local transactions, one per service. Each step commits locally, and triggers the next through an event or command.
• If a step in your saga fails, how do you keep data consistent? Give a specific compensation example. — A travel booking saga (flight → hotel → car): Flight booked (FLIGHT_HELD); Hotel booked (HOTEL_CONFIRMED); Car rental fails (no availability); The orchestrator runs the compensations in reverse: cancel the hotel booking (per the cancellation policy), then release or…
• How do you handle Kafka messages that several different services must consume, each with its own logic? — Publish once to one topic. Give each service its own consumer group (group.id=notification-service, group.id=analytics-service, group.id=fraud-service).
• You need Kafka for real-time notifications in a social media application. How would you set it up? — Events: domain services publish PostLiked, CommentAdded, UserFollowed and so on to topics keyed by the recipient's user ID, to preserve per-user ordering. Use the transactional outbox for reliability; The notification service (@KafkaListener, its own consumer group,…
• With User, Order and Payment services, how would you handle communication between them? Synchronous or asynchronous? — Choose per interaction: Synchronous (REST or gRPC) when the caller needs the answer to continue, and the user is waiting. For example: Order → User: validate the customer, or fetch the address. Better still, keep a local replica built from UserUpdated events, to avoid the…
• When several services must update shared data, how do you ensure consistency? Distributed transactions or eventual consistency? — First, remove the "shared data". Give it one owner service. Others change it only through that owner's API or commands, and read it through replicated read models; Eventual consistency (the default): Sagas.

Tracing, Discovery, Load Balancing, Service Mesh & Resilience — Interview Questions — open the lesson

• How do you implement tracing in a microservices architecture? — Use distributed tracing: Each request gets a trace ID, and each unit of work a span ID; They're propagated across service calls in W3C traceparent headers (and in message headers for Kafka); Spans are exported to a tracing backend, which shows the whole call tree with timings.
• How can you track the flow of requests across multiple microservices? — Combine the three pillars, linked together by the trace ID: Traces (Jaeger, Zipkin, Tempo): the request's path, per-hop latency, and which service errored; Correlated logs: every log line carries traceId, so you can jump from a trace to its logs in Kibana or Loki; Metrics…
• Which service discovery tools have you implemented? What configuration is needed in the application or the Kubernetes cluster? — Name the two you've used, with their setup: Netflix Eureka (Spring Cloud Netflix): Run a Eureka server (@EnableEurekaServer, clustered for HA); HashiCorp Consul: Add spring-cloud-starter-consul-discovery, and set spring.cloud.consul.host/port; Kubernetes-native (the…
• How would you implement service discovery? What's the difference between client-side and server-side discovery? — Client-side discovery: The client queries the registry (Eureka or Consul), gets the instance list, and picks one itself, with a client-side load balancer (Spring Cloud LoadBalancer); Server-side discovery: The client calls a stable address (a load balancer, a Kubernetes…
• Which load balancer do you use, and how do you configure it with Kubernetes or the cloud? — There are layers of load balancing: Inside the cluster, a Kubernetes Service (ClusterIP) balances across the ready pods. That's L4, through kube-proxy or eBPF; North-south traffic: a cloud load balancer (AWS ALB/NLB, GCP LB, Azure) in front of an ingress layer: the NGINX…
• What is a service mesh? — A dedicated infrastructure layer for service-to-service communication. Proxies (Envoy sidecars, or Istio's ambient mode with node-level proxies; Linkerd uses its own micro-proxy) intercept all the traffic, and a control plane configures them. It gives you, without application…
• What do you use for application resilience? — Resilience4j (through Spring Cloud CircuitBreaker, or its Spring Boot starter), combining: Timeouts (TimeLimiter, plus the HTTP client's connect and read timeouts): the first line of defence. Never wait forever; Retries with exponential backoff and jitter, only for transient…
• Describe a scenario where a microservice might fail. How would you implement a circuit breaker to keep the system resilient? — Scenario: during a sale, the external payment provider slows down to 20 s responses. The Order service's request threads pile up waiting, its connection pool drains, and checkout, and then the whole site, stops responding.

Deployment, Scaling & Security for Microservices — Interview Questions — open the lesson

• You're designing a microservices architecture, and service failures must not take down the whole system. What strategies would you use? — Isolate, degrade and recover.
• What's the difference between Docker and Kubernetes? — Docker is a container toolchain: It builds images (Dockerfile or BuildKit), and runs containers on one host (Docker Engine, on containerd); Kubernetes is a container orchestrator for a cluster of machines: scheduling.
• When deploying a microservices application, how would you decide between Docker, Kubernetes, or both? — You almost always build with Docker (or buildpacks or Jib). The question is what runs the containers: Docker (Compose) alone: local development, CI test environments, or a small, single-host deployment with a few services and low availability needs; Kubernetes: many services;…
• Describe how you dockerised a Spring Boot application: the steps, challenges and benefits. — Steps: A multi-stage Dockerfile: build with Maven or Gradle in a JDK stage, then copy the extracted layered JAR into a slim JRE runtime stage. Or use spring-boot:build-image (buildpacks) or Jib, with no Dockerfile at all; Challenges: JVM memory in containers: use…
• What security practices do you follow when developing microservices? — Identity and access: A central identity provider (OAuth2/OIDC); every service validates JWTs as a resource server; Encryption in transit: TLS at the edge, and mTLS between services (often through a mesh); Secrets: a vault or cloud secret manager, rotated. Never in images, Git…
• What are the security challenges in microservices, and how would you secure service-to-service communication? — The challenges: A larger attack surface: many endpoints and network paths; The strategies for service-to-service calls: mTLS everywhere, ideally through a service mesh: automatic certificates, rotation, and SPIFFE workload identities.
• How would you scale one or many microservices? Is application.yml enough, or do you have to configure the cloud environment too? — Scaling is mostly a platform concern. application.yml alone is not enough.
• One of your microservices is under high load. How would you approach scaling it, and what would you consider? — Diagnose the resource: Is it CPU-bound (serialisation, computation)?; Match the fix to the cause: CPU: scale out horizontally, and optimise hot code paths; Scale safely: Check the downstream capacity (database connections = replicas × pool size); Consider cost vs benefit:…

Microservice Design Patterns

API Gateway, Circuit Breaker & Retry Patterns — Interview Questions — open the lesson

• What is the API Gateway pattern for? — A gateway is a single entry point for all client requests to a microservices system. It: routes each request to the right service; handles cross-cutting concerns centrally: authentication and token validation, rate limiting, TLS termination, CORS, logging and metrics, request…
• What is the Circuit Breaker pattern for? — It stops a service from repeatedly calling a dependency that's failing or too slow: After a failure threshold, it fails fast, for a cool-down period, often with a fallback; That prevents cascading failures (thread and connection exhaustion in the caller), and gives the…
• What is the Retry pattern for? — It automatically re-attempts a failed operation when the failure is likely transient: a network blip, a timeout, a 503 during a deployment, a lost connection, or a rate-limit response with a Retry-After.
• What is the API Gateway pattern, and why is it important in microservices? — Without a gateway, clients must know every service's address, API and authentication scheme. Every service must re-implement the edge concerns, and internal refactoring breaks clients. The gateway: decouples clients from the internal topology (services can be split, merged or…
• How does an API Gateway improve security and performance? — Security: Terminates TLS.; Performance: Response caching for cacheable GETs.
• What's the difference between using an API Gateway and letting clients call microservices directly? — Compared side by side in the full answer (table) — know each row.
• What are the common challenges of implementing an API Gateway? — A single point of failure or bottleneck: run several instances across zones, autoscale, and keep it stateless. Rate-limit state belongs in Redis; Added latency: keep the filters lightweight, use non-blocking gateways (Spring Cloud Gateway on Netty, or Envoy), and pool the…
• What is the Circuit Breaker pattern, and how does it improve resilience? — The breaker wraps calls to a dependency, and tracks their outcomes (failures and slow calls) in a sliding window. When the failure rate crosses a threshold, it opens, rejecting calls immediately (CallNotPermittedException), which triggers a fallback. It improves resilience…
• Explain the circuit breaker's states: closed, open and half-open. — CLOSED (normal): calls pass through, and results are recorded. If the failure rate or slow-call rate in the window reaches the threshold (after a minimum number of calls), it moves to OPEN; OPEN: all calls are rejected immediately (the fallback runs) for…
• How does the Circuit Breaker pattern differ from the Retry pattern? — They handle different kinds of failure: Retry is optimistic: it assumes the failure is momentary, and tries again soon, to turn a transient error into a success for this request; The circuit breaker is pessimistic: it assumes the failure is persistent, and stops trying for a…
• When would you use a circuit breaker in a microservices architecture? — On every remote call where a slow or failing dependency could hurt the caller: External third-party APIs (payment, SMS, shipping carriers, maps), which you don't control; Internal services in synchronous chains on the critical path; Shared infrastructure calls (a search…
• What is the Retry pattern, and when should you use it? — Use it for transient failures on idempotent operations: Retry: connection resets, timeouts (only if the operation is idempotent, or carries an idempotency key), HTTP 502/503/504, 429 with Retry-After, deadlocks or serialisation failures in the database, leader elections in…
• How does the Retry pattern improve fault tolerance? — Many distributed failures are brief and self-healing: packet loss, a pod restarting during a rolling deployment, a leader failover, a momentary pool exhaustion. Retrying with a short backoff masks these blips from users and upstream services. That means: fewer error responses…
• What's the relationship between the Retry and Circuit Breaker patterns? — They're complementary. The usual composition is Retry outside, Circuit Breaker inside (Resilience4j's default aspect order): Retry handles an individual transient failure; Every attempt is recorded by the breaker. When failures persist, the breaker opens, and later retries…
• What strategies limit retries, and avoid overwhelming downstream services? — Bounded attempts: 2–3 at most, and an overall deadline or timeout budget propagated downstream; Exponential backoff: 200 ms, 400 ms, 800 ms…, with a maximum delay; Jitter: randomise the delays (full or decorrelated jitter), so thousands of clients don't retry in sync (the…

Service Discovery & Database per Service Patterns — Interview Questions — open the lesson

• What is the Service Discovery pattern for? — In dynamic environments, instances come and go: autoscaling, deployments, failures, and new IP addresses. Service discovery keeps a live registry of the healthy instances of each service.
• What is the Database per Microservice pattern for? — Each service owns its data store, private to it. Others access that data only through its API or events. This gives loose coupling, independent schema evolution, independent scaling, and polyglot persistence.
• What is the purpose of the Service Discovery pattern in microservices? — It's the system's dynamic address book, plus health filter: It decouples callers from network locations: a logical name (inventory-service) maps to the current addresses; It tracks health through heartbeats, TTLs or health checks, so traffic goes only to live instances; It…
• How do client-side and server-side service discovery differ? — Client-side: the caller queries the registry, and load-balances itself. Examples: the Eureka client with Spring Cloud LoadBalancer, or a Consul client; Server-side: the caller sends to a router or load balancer (a Kubernetes Service, AWS ALB, a gateway, a mesh sidecar), which…
• Which tools are commonly used for service discovery? — Netflix Eureka: An AP registry (it favours availability; its self-preservation mode keeps stale entries during network partitions); HashiCorp Consul: A CP registry, built on Raft; Kubernetes built-in: Services + DNS (CoreDNS) + EndpointSlices, fed by readiness probes; Others:…
• How does Service Discovery help with horizontal scaling? — Scaling out means launching new instances, with new, unpredictable addresses. With discovery: new instances register automatically once healthy (or become ready in Kubernetes); callers and load balancers pick them up on the next registry refresh, and spread the traffic across…
• Why is a separate database for each microservice recommended? — Loose coupling: with a shared database, the schema is the API. Any team's migration can break other services, and deployments become coupled: a "distributed monolith"; Autonomy: each team evolves its schema, and deploys, on its own schedule; Independent scaling and…
• What are the challenges of managing multiple databases in microservices? — Distributed consistency: there are no cross-service ACID transactions, so you need sagas and eventual consistency; Cross-service queries and joins are impossible directly. You need API composition, or read models; Data duplication: services keep copies of others' data…
• How do you handle data consistency across microservices with separate databases? — Prefer event-driven eventual consistency, over distributed transactions: Sagas (choreographed or orchestrated): local transactions plus compensations; The transactional outbox, or CDC, to publish events atomically with the state change; Idempotent consumers (at-least-once…
• What strategies can be used to replicate or synchronise data between microservices? — Domain events (application-published): the owner publishes CustomerUpdated, and consumers update their local read copies. Use the outbox for reliability. The events are meaningful business contracts; Change Data Capture: Debezium reads the owner database's transaction log…

Saga, Choreography & Orchestration Patterns — Interview Questions — open the lesson

• What is the Saga pattern for? — It manages a business transaction that spans several services, each with its own database, without a global ACID transaction.
• What is the Choreography pattern for? — Services collaborate by publishing and reacting to events, with no central coordinator. Each service decides for itself what to do when it sees an event.
• What is the Orchestration pattern for? — A central orchestrator owns the workflow. It sends commands to the services in a defined sequence, waits for their replies, applies branching, timeouts and retries, and runs compensations on failure.
• The Saga pattern: the core idea, in one line. — "Replace one distributed ACID transaction with a sequence of local transactions, each publishing the next step, and each paired with a compensating transaction that semantically undoes it." Sagas are ACD, not ACID: they're atomic (through compensation), consistent and…
• What is the Saga pattern, and how does it manage distributed transactions? — Each step is a local transaction in one service. It commits, and emits an event or reply (reliably, through the outbox); The next step is triggered by that event (choreography) or by the orchestrator's next command (orchestration); If a step fails, the compensating…
• What's the difference between choreography and orchestration in a saga? — Compared side by side in the full answer (table) — know each row.
• What are compensating transactions, and how are they used in a saga? — A compensating transaction is a business operation that semantically reverses a previously committed step, when a later step fails: ReserveStock → ReleaseStock; AuthorisePayment → VoidAuthorisation (or Refund after capture); BookFlight → CancelFlight.
• In what scenarios is the Saga pattern useful? — Multi-service business processes that must complete all or nothing, logically: order placement (order, inventory, payment, shipping); Long-running transactions, lasting minutes or days (approvals, human steps), where holding locks is impossible; Integrations with external…
• What is the Choreography pattern, and how does it work? — A service completes a local transaction, and publishes a domain event (through the outbox) to a broker topic; Interested services subscribe (each with its own consumer group), perform their own local transaction, and publish their own events; The workflow emerges from this…
• How does choreography promote loose coupling between microservices? — Publishers don't know who consumes their events, and consumers don't call publishers. They share only event contracts (schemas); New consumers can be added (a fraud check, loyalty points) without changing the publisher; Services are decoupled in time: a consumer can be down,…
• What are the pros and cons of event-driven architecture (choreography)? — Pros: Loose coupling and independent evolution; Cons: The overall flow is hard to see: debugging needs distributed tracing, and correlation IDs.
• Give an example of how events coordinate services in a choreography model. — E-commerce order flow.
• What is the Orchestration pattern, and how does it differ from choreography? — In orchestration, a dedicated orchestrator (a saga manager, or a workflow engine such as Temporal, Camunda, Netflix Conductor, AWS Step Functions, or a Spring State Machine-based service) explicitly drives the workflow.
• How does an orchestrator control the interactions between microservices in a workflow? — It persists the saga state (the current step, the data collected, the attempts) durably, so it survives crashes, and resumes where it left off; It sends commands to participants, asynchronously through command topics or queues, or synchronously through APIs, each with a…
• What are the advantages and disadvantages of using an orchestrator? — Advantages: The workflow lives in one explicit place: easy to understand, change, test and audit; Disadvantages: A central component to run, scale and keep highly available. Engines like Temporal are built for this, but it's still infrastructure.
• Give a real-world use case for the Orchestration pattern. — A travel package booking.

Bulkhead & Strangler Fig Patterns — Interview Questions — open the lesson

• What is the Bulkhead pattern for? — It partitions resources (thread pools, connection pools, concurrency limits, instances), so a failure or overload in one part can't exhaust the resources that other parts need.
• What is the Strangler pattern for? — It replaces a monolith gradually. New microservices are built alongside it, a routing facade sends more and more functionality to them, and the monolith's corresponding code is retired, until nothing is left (the "strangler fig" vine that eventually replaces its host tree).
• What is the Bulkhead pattern, and how does it prevent system-wide failures? — Most cascading failures are resource exhaustion. One slow dependency holds threads and connections until none are left for anything else, so the healthy features fail too. Bulkheads put a hard cap on how much of a shared resource any one dependency, tenant or feature can…
• How do you implement bulkheads in a microservices architecture? — Implement them at several levels: In code (per dependency): Resilience4j SemaphoreBulkhead: caps the concurrent calls. Works well with virtual threads; Per workload type: separate consumer groups or listener containers for critical and bulk topics, and separate database pools…
• Give an example where the Bulkhead pattern improves reliability. — Online banking. The Transactions (payments), Account and Support services each have: their own deployments, pools and quotas; inside the Transactions service, separate thread pools for the core ledger and for calls to the slow fraud-scoring and statement-PDF services.
• How does the Bulkhead pattern relate to resource isolation? — A bulkhead is resource isolation, applied deliberately to contain failures. The resources isolated include: compute: CPU and memory requests and limits per pod, dedicated node pools; concurrency: threads, semaphores, virtual-thread limits; connections: separate database and…
• What is the Strangler pattern, and how is it used to migrate a monolith? — Put a routing facade in front of the monolith: an API gateway, a reverse proxy, or an ingress; Build one capability as a new service; Route that capability's traffic (by path, header, user cohort or percentage) to the new service; Keep everything else on the monolith; …
• What are the key benefits of the Strangler pattern for modernisation? — Lower risk: no big-bang cut-over. Each slice can be canaried and rolled back by switching a route; Continuous value delivery: new services go live early, and the business isn't frozen for a multi-year rewrite; Learning as you go: the team builds platform, observability and…
• How would you implement the Strangler pattern incrementally in a legacy system? — Prepare: Put the facade in front, with no behaviour change; Choose the first slice: loosely coupled, valuable and low-risk (for example notifications or catalogue search). Avoid the core transactional heart first; Build the service: its own data store, API and pipeline. Use…
• What challenges arise when applying the Strangler pattern to a monolith? — Data entanglement: shared tables, cross-module joins, and transactions spanning the migrated and non-migrated parts. Splitting the data is usually the hardest part. It needs CDC or sync, and a clear ownership flip; Dual running: two implementations must behave identically…

Follow-up questions this topic invites — and their answers

Q: How should I use this list in the last week before an interview? A: Do one pass per day. Cover the answer text, say your answer out loud, then check it. Mark every question you could not answer crisply, and spend your study time only on the marked ones by opening the linked full answer. By the third pass the marked list should be short.

Q: The interviewer asks one of these basics — should I give only the one-liner? A: Lead with the one-liner, then add one concrete detail or example from your own work. At this level the follow-up usually probes the mechanism behind the basic answer, so be ready to go one layer deeper using the key points in the full lesson.

Q: Some answers here were corrected compared with common prep sheets — why? A: Several widely shared answers are outdated or wrong (for example, Java version details, removed Spring APIs, or SQL queries that miss edge cases). The full lessons call these out under "Common trap" — reading those is the fastest way to stand out from candidates who memorised the same sheets.