Microservices Architecture Interview Questions and Answers

Microservices interviews are not vocabulary tests — they are judgement tests. Interviewers want to see whether you can split a system sensibly, defend the boundaries you drew, and stay honest about the distributed-system costs you took on. This set walks the twelve architecture questions that come up most, each with a fast answer, the reasoning underneath, and the follow-up that catches candidates who learned the buzzwords but not the trade-offs.

Why interviewers ask about microservices architecture

Microservices are easy to describe and hard to get right, so interviewers use them to separate people who have read blog posts from people who have felt the pain. The give-away is trade-off awareness: a strong candidate volunteers the costs of microservices before being asked.

The questions also probe distributed-systems thinking. The moment you split one process into many, you inherit network failures, eventual consistency and partial outages — problems a monolith never had. How you talk about those problems reveals your real level far more than reciting the definition of a service.

How to answer in an interview

Frame every answer around trade-offs, not advocacy. "Microservices let teams deploy independently, at the cost of network latency and distributed transactions" is a mature sentence; "microservices are scalable and modern" is a red flag. Always pair a benefit with its price.

Ground abstract patterns in a concrete system — an e-commerce platform with order, payment and inventory services works well. If the fundamentals feel shaky, review the microservices architecture explained guide and the monolith vs microservices comparison before drilling.

Q1. What are microservices and how do they differ from a monolith?

Microservices structure an application as a set of small, independently deployable services, each owning one business capability and its data, communicating over the network. A monolith packages all capabilities into one deployable unit sharing one database.

The operative word is "independently deployable" — you can release the payment service without rebuilding order. That independence is the core benefit and the source of every complication that follows.

Interview note: Trap: "so microservices are just small monoliths?" No — size is not the point. A microservice is defined by independent deployability and owned data, not line count. A small tightly-coupled service is not a microservice.

Q2. When should you NOT use microservices?

For small teams, early-stage products, or simple domains. Microservices add network calls, distributed transactions, service discovery, deployment pipelines and monitoring overhead. Until you have the scale or the independent teams to justify that cost, a well-structured monolith ships faster and breaks less.

Volunteering this is one of the strongest things you can do in a microservices interview. It shows you see the architecture as a trade-off, not a trophy. Many companies succeed by starting monolithic and extracting services only when a boundary proves stable.

Interview note: Follow-up: "how do you migrate a monolith to microservices?" Incrementally — the strangler pattern: route new or extracted capabilities to new services while the monolith shrinks, rather than a risky big-bang rewrite.

Q3. How do you decide service boundaries?

Around business capabilities, using domain-driven design. Each service should map to a bounded context — a cohesive area of the domain with its own model and language. Draw boundaries where the business does, not around technical layers.

The classic failure is layer-based decomposition — a "database service," a "UI service" — which couples everything and forces chatty cross-service calls for one use case. Capability-based boundaries keep a change local to one service.

Interview note: Trap: "how big should a microservice be?" Not a line count — it should be ownable by one small team and encapsulate one bounded context. "Small enough to rewrite in a sprint" is a heuristic, not a rule.

Q4. What is the database-per-service pattern?

Each service owns its own database and no other service reads or writes it directly — access goes through the owning service's API. This keeps services decoupled and independently deployable, at the cost of losing cross-service joins and single ACID transactions.

order-service    -> orders_db
payment-service  -> payments_db
inventory-service-> inventory_db   (no shared tables, no cross-DB joins)

Sharing a database is the anti-pattern that quietly turns microservices back into a distributed monolith — a schema change in one service breaks another. Owning data is what makes independence real.

Interview note: Follow-up: "how do you report across services if each has its own DB?" A separate read model / data warehouse fed by events, or an API composition query — never a direct join across service databases.

Q5. What does an API gateway do?

It is the single entry point for clients. It routes each request to the right service and centralises cross-cutting concerns — authentication, rate limiting, TLS termination, and request aggregation — so services and clients do not each reimplement them.

Without a gateway, every client must know each service's address and duplicate auth and throttling logic. The gateway also lets you evolve the internal topology without breaking clients. Detail lives in the API gateway guide.

Interview note: Trap: "isn't the gateway a single point of failure and a bottleneck?" It can be, which is why you run it redundantly behind a load balancer and keep it thin — routing and cross-cutting concerns only, no business logic.

Q6. How does service discovery work?

Services register themselves with a registry (Eureka, Consul) on startup, and callers look up healthy instances by logical service name instead of hard-coded IPs. The registry tracks which instances are alive as they scale up, down and move.

This exists because cloud instances are ephemeral — IPs change constantly. Client-side discovery has the caller query the registry and pick an instance; server-side discovery hides it behind a load balancer. Either way, no address is hard-coded.

Interview note: Follow-up: "client-side vs server-side discovery?" Client-side gives the caller control over load-balancing but couples it to the registry; server-side (a load balancer or gateway) hides discovery from the client at the cost of an extra hop.

Q7. How do microservices communicate — synchronous vs asynchronous?

Synchronous over HTTP/REST or gRPC when the caller needs an immediate response; asynchronous over a message broker (Kafka, RabbitMQ) when you want decoupling and resilience. Async lets a service publish an event and not wait, so a downstream outage does not block the caller.

The trade-off: synchronous is simple but creates temporal coupling — if payment is down, order is stuck. Asynchronous is resilient but introduces eventual consistency and more moving parts. Real systems mix both.

Interview note: Trap: "why not make everything synchronous, it's simpler?" Because a chain of synchronous calls multiplies latency and failure probability — one slow service stalls the whole request. Async breaks that coupling.

Q8. How do you handle failure of one service without cascading?

With resilience patterns: timeouts so a caller does not wait forever, retries with backoff for transient faults, and a circuit breaker that stops calling a failing service and fails fast, giving it time to recover. Bulkheads isolate resource pools so one slow dependency cannot exhaust all threads.

A cascading failure is the signature microservices outage: one slow service backs up its callers until the whole system stalls. The circuit breaker is the key defence — covered in the design patterns interview set.

Interview note: Follow-up: "what does a circuit breaker do when open?" It short-circuits calls and returns a fallback immediately instead of hitting the failing service, then periodically half-opens to test recovery.

Q9. How do you maintain data consistency across services?

With eventual consistency and the saga pattern instead of a distributed transaction. A saga is a sequence of local transactions coordinated by events, where each step has a compensating action to undo it if a later step fails.

Because each service owns its database, a single ACID transaction across services is impossible without heavy, brittle two-phase commit. Sagas trade immediate consistency for availability and decoupling — the standard microservices choice.

Interview note: Trap: "why not use two-phase commit for correctness?" It locks resources across services, kills availability, and couples them tightly — the opposite of what microservices are for. Sagas with compensation are preferred.

Q10. How do you observe and debug a distributed system?

With the three pillars of observability: centralised logging (correlated by a trace ID), metrics (per-service latency, error rate, throughput), and distributed tracing that follows one request across every service it touches. Health checks feed the orchestrator's decisions.

The hard part of microservices debugging is that one user action spans many services, so a stack trace is not enough. A correlation ID threaded through every call is what lets you reconstruct the journey. See observability vs monitoring.

Interview note: Follow-up: "difference between monitoring and observability?" Monitoring answers known questions with predefined dashboards; observability lets you ask new questions about unexpected behaviour from rich telemetry you did not predict in advance.

Q11. What is the difference between choreography and orchestration?

Orchestration uses a central coordinator that tells each service what to do next — explicit and easy to follow but a coupling point. Choreography has services react to each other's events with no central brain — loosely coupled but harder to trace end to end.

The choice is a trade-off between visibility and coupling. Orchestration suits complex workflows needing clear control; choreography suits simple, highly decoupled event flows. Naming both and their trade-off is the complete answer.

Interview note: Trap: "which is better?" Neither universally — orchestration for workflows you must reason about centrally, choreography for maximum decoupling. Many systems use orchestration for critical flows and choreography for the rest.

Q12. How do you secure a microservices architecture?

Authenticate at the edge (API gateway) and propagate identity as a token (JWT/OAuth2) that each service validates. Use mutual TLS for service-to-service calls, apply least-privilege authorization per service, and never trust the network — assume any service could be compromised.

The principle is zero trust: internal calls are authenticated too, not assumed safe because they are "inside." The gateway handles edge auth; each service still verifies the token. More in microservices security best practices.

Interview note: Follow-up: "where do you validate the token — gateway or service?" Both: the gateway rejects obviously invalid requests early, but each service re-validates because it must not trust that a call came through the gateway.

How to prepare

Sketch one system — an e-commerce platform is ideal — and decompose it into services by business capability. For each, decide what data it owns, how it talks to its neighbours (sync or async), and how it fails safely. Drawing this once turns abstract questions about boundaries, discovery and consistency into decisions you have actually reasoned through.

Rehearse the "when NOT to use microservices" answer (Q2) and the service-boundary reasoning (Q3) — volunteering the trade-offs is what marks you as experienced. Then pair this with the microservices design patterns questions and the deeper microservices interview questions guide. Distributed-systems judgement like this is exactly what our Java Full Stack with AI program develops through real project work.