Microservices solve organisational problems and create technical ones. These questions check whether a candidate understands the tradeoffs, not just the buzzword.
Hiring a Microservices developer is easy. Telling a real one from a convincing résumé is the hard part — and it’s most of what we do. These are grouped by level, because the same question that stretches a junior is a warm-up for a senior.
Junior Microservices interview questions
0–2 years
Fundamentals.
What are microservices?
An architecture splitting an application into small, independently deployable services owning their own data and logic.
Thinks any app split into files is “microservices.”
What are the tradeoffs vs a monolith?
Independent deployment and scaling and team autonomy, at the cost of operational complexity, distributed-system problems and latency.
Sees only upsides.
How do services communicate?
Synchronously (HTTP/gRPC) or asynchronously (messaging/events), each with different coupling and reliability characteristics.
Only knows synchronous calls.
Why should each service own its data?
To stay independently deployable and loosely coupled; sharing a database recreates a distributed monolith.
Has multiple services share one database directly.
What is an API gateway?
A single entry point handling routing, auth, rate limiting and aggregation in front of services.
Exposes every service directly to clients.
What is service discovery?
A mechanism for services to find each other’s network locations dynamically rather than hardcoding addresses.
Hardcodes service URLs.
What is the difference between synchronous and asynchronous communication?
Synchronous waits for a response and couples availability; asynchronous decouples via messages/events and tolerates outages.
Uses synchronous calls where events would be more resilient.
Why is a distributed system harder than a monolith?
Network calls fail, latency is real, and consistency across services is hard; you must design for partial failure.
Assumes network calls always succeed instantly.
Mid-level Microservices interview questions
2–5 years
Data and communication.
How do you handle data consistency across services?
Embrace eventual consistency with events, sagas for multi-step workflows, and the outbox pattern — avoiding distributed transactions.
Tries to span an ACID transaction across services.
What is the saga pattern?
Coordinating a business transaction across services as a series of local transactions with compensating actions on failure.
Assumes a rollback across services is possible.
How do you prevent cascading failures?
Timeouts, retries with backoff, circuit breakers and bulkheads so one failing dependency doesn’t take everything down.
Calls downstream services with no timeout.
What is the difference between orchestration and choreography?
Orchestration has a central coordinator; choreography has services react to events independently — each with tradeoffs in coupling and visibility.
Doesn’t know either coordination style.
How do you define service boundaries?
Around business capabilities/domains (bounded contexts), not technical layers, to minimise cross-service chatter.
Splits by technical layer, creating chatty services.
How do you handle distributed tracing and observability?
Correlation IDs and tracing across service hops, plus centralised metrics and logs, since a request spans many services.
Debugs one service at a time with no correlation.
How do you version and evolve service contracts?
Backward-compatible changes, consumer-driven contract testing, and coordinated deprecation.
Changes a contract and breaks consumers silently.
How do you handle shared logic across services?
Shared libraries carefully (to avoid tight coupling) or duplicated where independence matters more than DRY.
Creates a shared library that couples every service’s release.
Senior Microservices interview questions
5+ years
Architecture and operations.
When should you NOT use microservices?
Early-stage products, small teams, or unclear domains — a monolith is usually the right starting point until scale and org needs justify the complexity.
Starts a greenfield product with dozens of services.
How do you decompose a monolith safely?
Identify bounded contexts, extract seams incrementally (strangler pattern), and split data carefully rather than a big-bang rewrite.
Proposes a risky big-bang rewrite.
How do you manage distributed transactions and idempotency?
Idempotency keys, at-least-once messaging with deduplication, and sagas — assuming messages can arrive twice or out of order.
Assumes exactly-once delivery.
How do you handle deployment and versioning at scale?
Independent CI/CD per service, backward-compatible contracts, and progressive delivery so services deploy without lockstep.
Requires all services to deploy together.
How do you approach resilience and failure testing?
Design for partial failure and validate with chaos/failure testing, load testing and graceful degradation.
Assumes the happy path always holds.
How do you avoid the “distributed monolith” anti-pattern?
Loose coupling via async events, independent data and deployment, and boundaries that minimise synchronous chains.
Builds tightly-coupled services that must deploy together.
How do you manage cross-cutting concerns (auth, logging)?
Gateways, sidecars/service mesh, and shared standards rather than reimplementing them per service.
Reimplements auth and logging inconsistently everywhere.
How do organisational structure and Conway’s Law relate to microservices?
Service boundaries tend to mirror team structure; aligning teams to services (and vice versa) is key to their success.
Ignores team ownership and creates shared, unowned services.
Build and score a full interview with our free interview scorecard tool, browse the full question hub, or see how we interview engineers.