Interview Questions

Microservices Interview Questions and Answers

Microservices interviews focus heavily on tradeoffs -- interviewers want to see that you understand what you're giving up (simplicity, easy transactions) for what you gain (independent scaling and deployment), not just that you can define the term.

Example: Two services communicating over REST vs. events

Synchronous (REST): an order-service calls GET /inventory/{sku} on inventory-service directly and waits for the response before continuing. Simple, but if inventory-service is slow or down, order-service is blocked too. Asynchronous (event-driven): order-service publishes an OrderPlaced event to a message broker (like Kafka) and moves on immediately. inventory-service consumes that event independently, whenever it's ready. This decouples the two services' availability from each other, at the cost of eventual (not immediate) consistency.

Frequently Asked Questions

An approach to building a system as a set of small, independently deployable services, each owning its own data and a specific business capability, communicating over the network (via REST, messaging, or gRPC) rather than in-process function calls. It's the alternative to a monolith, where all functionality runs as one deployable unit.

Gains: independent deployment and scaling per service, teams can work autonomously, a failure in one service doesn't necessarily crash the whole system. Costs: distributed systems complexity (network calls can fail, latency, partial failures), harder to maintain data consistency across services, more operational overhead (more things to deploy, monitor, and version).

Synchronously via REST or gRPC (a direct call, waiting for a response), or asynchronously via a message broker like Kafka or RabbitMQ (publish an event, don't wait). Most real systems use a mix -- synchronous calls for requests that genuinely need an immediate answer, events for things that can happen eventually.

You generally can't use a traditional ACID database transaction across services with separate databases. Common patterns instead: the Saga pattern (a sequence of local transactions, each publishing an event that triggers the next step, with compensating actions to undo previous steps if a later one fails), or accepting eventual consistency for operations that don't need to be atomic.

A single entry point that sits in front of your microservices, routing external requests to the right internal service, and often handling cross-cutting concerns centrally -- authentication, rate limiting, request logging -- so individual services don't each reimplement them. It also hides internal service topology from external clients.

In a system where service instances scale up/down and get new network addresses dynamically, a service registry (like Eureka or Consul) tracks which instances are currently alive and where. Services register themselves on startup, and callers query the registry (often via a client-side load balancer) instead of hardcoding IP addresses.

Splitting a system into many small services before the team or the domain boundaries are ready for it -- ending up with a "distributed monolith" that has all the operational complexity of microservices but is still tightly coupled, so a change in one service still forces changes and redeploys across several others. Many experienced engineers recommend starting with a well-structured monolith and splitting out services only once real scaling or team-boundary pain justifies it.

Microservices Interview Questions and Answers

Example: Two services communicating over REST vs. events

Frequently Asked Questions

Related Guides

Sign in required