Microservices Interview Questions and Answers (2026)

Microservices split an application into small, independently deployable services, each owning a specific business capability and its own data, communicating over the network. A monolith ships as one deployable unit with one shared database. Microservices trade in-process simplicity for independent deployment, team autonomy and selective scaling — at the cost of network failure, data consistency and operational complexity.

Advantages: independent deploys and scaling, fault isolation, technology flexibility, and teams that can work without coordinating every release. Disadvantages: distributed-system problems (latency, partial failure), eventual consistency, harder testing and debugging, more infrastructure, and a real operational burden. The honest answer to "are microservices better?" is "it depends on team size and problem."

For small teams, early-stage products where the domain is still changing, or simple CRUD applications. A modular monolith — clear module boundaries in one deployable — is often the better starting point, and you can extract services later along boundaries you already understand. Many failed migrations split too early along the wrong lines.

Use Domain-Driven Design: identify bounded contexts, where a term has a single consistent meaning, and align services to business capabilities (orders, payments, inventory) rather than technical layers (a "database service"). Signs of bad boundaries: services that must always be deployed together, chatty calls between two services for every request, or two services sharing a table.

A boundary within which a domain model and its vocabulary are consistent. "Customer" means something different to billing than to support; each context has its own model, and services translate at the edges.

Synchronous (REST or gRPC) is simple and gives an immediate answer — fine for queries and when the caller truly needs the result. It creates temporal coupling: if the callee is down, the caller is affected. Asynchronous messaging (Kafka, RabbitMQ, SQS) decouples services in time and absorbs spikes, suits events and workflows, but makes flows harder to trace and results eventually consistent. Most real systems use both.

REST over JSON is ubiquitous, human-readable and easy to debug, a good fit for public APIs. gRPC uses HTTP/2 and Protocol Buffers: faster, strongly typed contracts, streaming, and generated clients — a good fit for internal service-to-service calls where performance and strict contracts matter.

A single entry point in front of services handling routing, authentication, rate limiting, TLS termination and request aggregation. It keeps cross-cutting concerns out of each service. The risk is turning it into a bottleneck or a place where business logic accumulates.

Services need to find each other as instances scale and move. Client-side discovery (a registry like Eureka or Consul that clients query) and server-side discovery (a load balancer or Kubernetes Services plus DNS) are the two models. On Kubernetes, the platform handles it for you.

Prefer backwards-compatible changes — add optional fields, never repurpose or remove them. When a breaking change is unavoidable, version the API (URL or header), run both versions during a deprecation window, and use consumer-driven contract tests (such as Pact) so you know who depends on what before you change it.

Shared databases create hidden coupling: a schema change in one service breaks another, and you can no longer deploy independently. Each service owns its data and exposes it only through its API or events. The cost is that you lose cross-service joins and ACID transactions.

You can't use a classic distributed transaction (two-phase commit) at scale — it's slow and fragile. The standard answer is the saga pattern: a sequence of local transactions, each publishing an event or command that triggers the next, with compensating transactions to undo earlier steps if a later one fails. Sagas can be choreographed (services react to each other's events) or orchestrated (a central coordinator drives the steps — easier to follow and monitor).

After a change, different services may briefly show different views, but they converge. Design the user experience around it — show "payment processing" rather than blocking, make operations idempotent, and decide per use case where strong consistency is genuinely required and keep that inside one service.

Updating your database and publishing an event are two separate actions — if one succeeds and the other fails you get inconsistency. With the transactional outbox, you write the business change and the event to an outbox table in the *same local transaction*, and a separate process (a poller or change-data-capture such as Debezium) publishes events from that table. You get at-least-once delivery without a distributed transaction.

CQRS separates the write model from read models, so reads can use denormalised, query-optimised stores. Event sourcing stores the sequence of events as the source of truth and derives current state from them. They're powerful for audit trails and complex domains but add significant complexity — and you don't need either for most services.

Messages can be delivered more than once, so processing must be safe to repeat. Use an idempotency key or message ID stored with the result, make operations naturally idempotent (set a value rather than increment), or use unique constraints that reject duplicates.

A wrapper around remote calls that tracks failures. After a threshold of failures it opens and fails fast instead of piling up requests against an unhealthy service, then periodically moves to half-open to test recovery. It prevents cascading failure. Libraries include Resilience4j; service meshes provide it at the infrastructure level.

Timeouts on every remote call (the most commonly missed), retries with exponential backoff and jitter (only for idempotent operations, and with limits to avoid retry storms), bulkheads (separate thread or connection pools so one slow dependency can't exhaust all resources), rate limiting, and graceful degradation — returning cached or reduced results when a non-critical dependency is down.

One slow service causes callers to queue up, exhaust threads and become slow themselves, spreading the failure upstream. Prevent it with timeouts, circuit breakers, bulkheads, load shedding and backpressure, and by testing failure deliberately (chaos experiments).

An infrastructure layer — usually sidecar proxies, as in Istio or Linkerd — that handles service-to-service concerns uniformly: mTLS, retries, timeouts, traffic shifting and telemetry, without changing application code. It adds operational complexity, so it's worth it mainly at scale or where strict security requirements apply.

A single request crosses many services, so logs on one machine tell you little. You need the three pillars: centralised logging with a correlation ID passed through every call, metrics (latency, error rate, saturation — the RED and USE methods) and distributed tracing (OpenTelemetry with Jaeger or Tempo) to see where time goes across the call chain.

Containerise each service, automate build-and-deploy pipelines per service, and use rolling, blue-green or canary releases with health checks and automatic rollback. Use feature flags to separate deployment from release. Our DevOps interview questions go deeper on CI/CD.

A pyramid: many unit tests, integration tests with real dependencies (Testcontainers), contract tests between services, and a small number of end-to-end tests — since those are slow and flaky. Test failure modes too: timeouts, malformed responses, and a downstream outage.

Externalise configuration from the build (environment variables, ConfigMaps, a config service), keep secrets in a dedicated manager (Vault, AWS Secrets Manager) rather than in images or repos, and keep one artifact promoted across environments.

Authenticate and authorise at the gateway for external traffic (OAuth 2.0 / OIDC with JWTs), propagate identity internally, and encrypt internal traffic with mTLS. Apply least privilege between services and don't assume the internal network is trusted.

Options: an API composition layer that calls the services and merges results (simple, but latency adds up and one failure breaks the page); or a read model built from events that each service publishes (fast reads, eventually consistent, more moving parts). Choose based on freshness requirements and read volume, and mention caching.

Look at distributed traces to find where time is spent, count the number of sequential network calls per request, check for chatty fan-out and missing timeouts, then consider parallelising calls, batching, caching, or reconsidering whether the boundary was drawn in the right place — a pair of services that always call each other may belong together.

Don't rewrite — use the strangler fig pattern: put a routing layer in front, extract one capability at a time (starting with something loosely coupled and valuable), migrate its data carefully, and route traffic gradually. Keep the monolith running until each piece is proven. Invest first in CI/CD and observability, because you'll need them.

There's no line-count rule. A service should be small enough that one team can understand and own it completely, and large enough to represent a coherent business capability. If a change usually requires editing several services together, they're probably too small or wrongly split.

Whichever your team knows well. Java with Spring Boot, Node.js, Go and Python are all common. Standardise enough (logging, tracing, build pipeline) that operating many services stays manageable.

No, but it is the common platform because it provides discovery, scaling, rollouts and self-healing. Smaller systems can run on simpler container platforms or even VMs; don't take on Kubernetes complexity before you need it.

Yes, but with more nuance than a few years ago — many teams now favour modular monoliths and extract services only where independent scaling or team autonomy justifies the cost. Showing that judgement in an interview is a strength.

Yes. Online IT job support provides live, hands-on help with real design, debugging and deployment issues in your own environment, aimed at you understanding and owning the solution.