System Design Interview Questions: Microservices Architecture

A microservices architecture breaks the application into small, independently deployable services, each owning a specific business capability. This is the defining characteristic of microservices — as opposed to a monolith, which packages everything into one unit. Services communicate over a network (e.g., HTTP/gRPC) and each manages its own data store.

False — sharing a single centralized database across microservices is an anti-pattern. It creates tight coupling between services, making independent deployment and schema evolution very difficult. The recommended practice is for each microservice to own its own dedicated data store and expose data to other services only through well-defined APIs.

The correct order is: (1) Identify bounded contexts and business capabilities, (2) Define API contracts, (3) Extract the service with its own data store, (4) Deploy independently behind an API gateway. You must understand domain boundaries first, agree on interfaces before coding, isolate data, and finally route live traffic — each step depends on the previous one.

The Circuit Breaker pattern is the most appropriate choice. It tracks failure rates to Service B and, once a threshold is exceeded, 'opens' the circuit so subsequent calls fail fast instead of blocking. This prevents Service A's thread pools from being exhausted waiting for a slow or unreachable dependency, allowing the system to degrade gracefully rather than cascade-fail.

This is false. A core microservices principle is that each service should own its own dedicated database ('Database per Service' pattern). Sharing a centralized database tightly couples services together — schema changes in one can break others, it creates a single point of failure, and it defeats independent deployability. Cross-service data consistency is handled through eventual consistency and patterns like Sagas.

The correct order is: Load Balancer / Ingress → API Gateway → Service Registry lookup → Target Microservice. In client-side service discovery (e.g., Netflix Eureka + Ribbon), the API Gateway itself queries the Service Registry to find a healthy instance before forwarding the request, making the registry lookup a distinct step that occurs after the gateway and before the microservice.

The genuine signals are that different parts need to scale independently at very different rates, that teams are stepping on each other because ownership boundaries are unclear, and that one module needs a completely different technology stack (such as a GPU inference service). A small, simple app one team can own comfortably, or a team with no operational maturity — no service discovery, tracing, or on-call culture — are anti-signals: start with a modular monolith.

Draw boundaries around business capabilities (or DDD bounded contexts) so that each service owns a cohesive area — orders, payments, inventory — rather than splitting by technical layer. A good boundary minimizes cross-service calls for a single operation and keeps a team able to ship that service independently. Each service owning its own database matters because it enforces loose coupling: no other service can reach into its tables, so the service is free to change its schema, and you avoid a shared database becoming a hidden coupling point and a single bottleneck. The cost is that data is now distributed, so a query spanning services needs an API call or an event, and a transaction across services needs a saga instead of a single ACID commit.

Microservices gain independent deployability (teams ship without coordinating a full release), targeted scalability (scale only the hot service), technology flexibility (choose the right tool per service), and fault isolation (one service crash doesn't bring down everything). The costs are network latency and failure modes that were formerly in-process function calls, distributed data consistency (no single ACID transaction across services), operational complexity (container orchestration, service discovery, distributed tracing), and testing overhead (you must test contracts between services, not just units). Microservices are usually the right call once team size and deployment frequency justify the coordination tax, not as a default starting point.

Goals & when to split. The pains are concrete: coupled deploys, no fault isolation, and an inability to scale checkout independently of browsing (which is ~50× the traffic). Those justify splitting. But microservices aren't free — they trade in-process calls and ACID transactions for network hops, partial failure, and distributed-transaction headaches. So I split deliberately, by business value, not everywhere at once.

Service boundaries. I decompose by bounded context / business capability: catalog, cart, orders, payments, inventory, shipping. Each is high-cohesion and owns its domain logic and its data. I avoid the anti-pattern of slicing along database tables into chatty anaemic services — boundaries follow how the business reasons about the domain, so services stay loosely coupled.

Database decomposition. Each service gets its own datastore (database-per-service) — this is what actually breaks the shared-DB scaling ceiling and SPOF. Services no longer cross-join each other's tables; instead they expose APIs and emit events. The orders service stores the product id (and denormalises the few fields it needs) and fetches the rest from the catalog API, or subscribes to catalog change events. What we give up is the convenient cross-table join and strong cross-entity consistency — replaced by API calls and eventual consistency.

Communication & gateway. An API gateway fronts everything: it authenticates, routes to the right service, rate-limits, and can fan out/aggregate. Between services I pick per interaction: synchronous REST/gRPC for a read I need right now (get product), asynchronous events for 'order placed' / 'inventory changed' so producers don't block on consumers. Every synchronous call is wrapped with timeouts, retries (idempotent), and a circuit breaker so a slow dependency fails fast instead of hanging the caller.

Cross-service correctness (place order). Placing an order spans orders + inventory + payments — three databases, so no single ACID transaction. I use a saga: a sequence of local transactions with compensating actions. Orchestrated, an order orchestrator does: reserve inventory → charge payment → confirm order; if payment fails after the reservation, it fires the compensation release inventory. The order sits in a PENDING state until the saga completes, and the user sees pending → confirmed (or failed). This is eventually consistent but never permanently leaks reserved stock.

Migration & new failure modes. No big-bang. I use the strangler-fig pattern: keep the monolith running behind the gateway, peel out one service plus its data at a time, route that capability's traffic to the new service (feature-flagged), dual-write / shadow-read to validate, then cut over and delete the monolith's copy. New failure modes — partial failure (one service down), cascading failure (a slow dependency dragging callers down), and added latency from hops — are contained with circuit breakers, bulkheads (isolate resource pools per dependency), idempotent retries with backoff, and distributed tracing so a request can be followed across services.