Microservices interview revision notes

What are microservices? (vs monolith)

Simple real-life example (Understand first — very important for understanding)

• Monolith: one big shop where everything—orders, inventory, billing—runs in one place; one deployment, one failure can affect all.
• Microservices: separate small shops (services), each doing one thing (orders, inventory, billing); each can be built, deployed, and scaled independently.

Real-world idea: microservices split an application into small, autonomous services that talk over the network. Each service owns its domain and can evolve and scale on its own.

Technical definition

• Microservices: many small services, each focused on one business capability, deployed independently, with their own data when possible.
• Monolith: single deployable unit; all logic and often one database. Simpler to start; harder to scale and change at large scale.
• Trade-off: microservices add complexity (network, discovery, distributed data); use when team size, scale, or release cadence justify it.

Simple practical example

E‑commerce: User Service, Order Service, Inventory Service, Payment Service. Each has its own API and DB; they call each other or use events.

Why it matters

Interviewers ask when to use microservices vs monolith and what problems microservices introduce (network failures, consistency, ops).

Interview tip

Say: "I use microservices when we need independent scaling, team autonomy, or different tech per service. I’d start with a monolith or modular monolith and split when boundaries are clear."

Service boundaries & domain-driven design

Simple real-life example (Understand first — very important for understanding)

• Like departments in a company: Sales, Warehouse, Finance—each has clear responsibility and owns its data; they coordinate via contracts, not by sharing each other’s desks.
• Bad boundaries: one service doing "everything" or two services fighting over the same data.

Real-world idea: draw boundaries around business capabilities (bounded contexts). Each service owns one context and exposes a clear API; avoid chatty or ambiguous boundaries.

Technical definition

• Bounded context (DDD): a clear part of the business with its own model and language; good unit for a microservice.
• Design around business capabilities (e.g. Order Fulfilment, User Identity), not technical layers (e.g. "database service").
• High cohesion inside a service; loose coupling between services; avoid shared databases.

Why it matters

Wrong boundaries cause tight coupling, big deployments, and data conflicts. This is a core system design topic.

Interview tip

Explain bounded contexts and designing services by business capability. Give an example (e.g. Order vs Payment vs Inventory) and why you wouldn’t share one DB.

Communication: sync (REST/gRPC) vs async (messaging)

Simple real-life example (Understand first — very important for understanding)

• Sync: like a phone call—you ask, wait, get an answer; if the other side is down, you’re stuck.
• Async: like email—you send a message and continue; the other side processes when ready. No need to wait, but you don’t get an immediate reply.

Real-world idea: use sync when you need an immediate response (e.g. get user). Use async (message queue, events) when you can defer work, decouple services, or handle bursts.

Technical definition

• Sync: REST, gRPC. Caller waits for response. Simple; coupling and latency; one failure can block the caller.
• Async: message queue (RabbitMQ, Kafka, SQS). Fire-and-forget or request/reply later. Decoupling, buffering; eventual consistency, need to handle duplicates and ordering.
• Prefer async for cross-service side effects (e.g. "order placed" → notify, reserve inventory) to avoid long chains of sync calls.

Code example

// Sync: HTTP call
const user = await fetch('http://user-service/users/1').then(r => r.json());

// Async: publish event
await messageQueue.publish('order.placed', { orderId, userId, items });

Why it matters

Choosing sync vs async affects availability, latency, and consistency. Interviewers often ask how services communicate and when to use queues.

Interview tip

Compare sync (REST/gRPC) vs async (events/queues). Say you’d use async for cross-service workflows and to avoid cascading failures and tight coupling.

API Gateway, service discovery & load balancing

Simple real-life example (Understand first — very important for understanding)

• API Gateway: one front desk that routes requests to the right department and can handle auth and rate limiting.
• Service discovery: a directory so you find "where is the order service today" (instances come and go). Load balancing: spread requests across healthy instances.

Real-world idea: clients talk to one entry point (gateway); the gateway and internal callers use discovery and load balancing to reach the right service instance.

Technical definition

• API Gateway: single entry for clients; routing, auth, rate limit, SSL; can aggregate or transform responses.
• Service discovery: registry (e.g. Consul, Eureka, K8s DNS) where services register; clients resolve service name to instances.
• Load balancing: distribute requests (round-robin, least connections, health-based); can be at gateway or client-side.

Why it matters

At scale you need a single entry, dynamic discovery, and load spreading. These are standard microservices interview topics.

Interview tip

Describe gateway (routing, auth, single entry), discovery (why we need it when instances scale), and load balancing (spread load, failover).

Data per service, eventual consistency & saga

Simple real-life example (Understand first — very important for understanding)

• Each department has its own files (data per service); no single shared filing cabinet. When one action spans departments (e.g. order + payment), they coordinate step by step—if one step fails, you may need compensating actions (saga).
• You accept that updates aren’t instant everywhere (eventual consistency).

Real-world idea: each service owns its database; cross-service transactions are avoided. For multi-step workflows you use sagas (sequence of local steps + compensations) and eventual consistency.

Technical definition

• Database per service: no shared DB; services expose APIs; avoid distributed 2PC for business transactions.
• Eventual consistency: data replicates or updates asynchronously; temporarily inconsistent; need idempotency and conflict handling.
• Saga: sequence of local transactions; each step has a compensating action if a later step fails (choreography: events; orchestration: central coordinator).

Why it matters

Data ownership and consistency are the hardest part of microservices. Interviewers ask how you do cross-service transactions and handle failures.

Interview tip

Explain database per service, why you avoid distributed transactions, and how sagas (with compensations) and eventual consistency fit in. Mention idempotency.

Deployment, containers & orchestration

Simple real-life example (Understand first — very important for understanding)

• Containers: packed boxes that run the same way on any truck (server)—no "works on my machine."
• Orchestration: a manager that places boxes on trucks, restarts failed ones, and scales when load increases.

Real-world idea: containers (e.g. Docker) package the app and its runtime; orchestration (e.g. Kubernetes) runs many containers, scales them, and keeps them healthy.

Technical definition

• Container: isolated process with its own filesystem; image = snapshot of app + dependencies; portable across environments.
• Orchestrator (Kubernetes): schedules pods (containers), handles replication, rolling updates, service discovery, config/secrets, health checks.
• Benefits: consistent envs, fast deploys, scaling, resilience (restart, replace).

Why it matters

Microservices are usually deployed as containers and orchestrated. You don’t need to know K8s in depth but should know the concepts.

Interview tip

Say: "We run each service in containers for consistency and portability; we use an orchestrator like Kubernetes for deployment, scaling, and health management."

Resilience: circuit breaker, retries & timeouts

Simple real-life example (Understand first — very important for understanding)

• If a shop is closed, you don’t keep knocking every second—you stop trying for a while (circuit breaker), then try again later.
• Retries: try a few times for transient failures. Timeouts: don’t wait forever; fail fast and let the caller handle it.

Real-world idea: networks and services fail. Use timeouts, limited retries, and circuit breakers so one failing service doesn’t bring down everyone.

Technical definition

• Timeout: max wait for a call; avoid hanging threads and cascading delays.
• Retry: retry with backoff (exponential) for transient failures; make operations idempotent where possible.
• Circuit breaker: after N failures, stop calling (open); after a cooldown try again (half-open); then resume (closed). Protects downstream and fails fast.

Code example

// Timeout
const res = await fetch(url, { signal: AbortSignal.timeout(5000) });

// Retry with backoff (pseudo)
for (let i = 0; i < 3; i++) {
  try { return await call(); }
  catch (e) { await sleep(100 * 2 ** i); }
}

Why it matters

Distributed systems need resilience patterns. Circuit breaker and retries are very common interview topics.

Interview tip

Explain timeout, retry with backoff, and circuit breaker (open/half-open/closed). Say you use them to avoid cascading failures and give downstream time to recover.

Observability: logging, tracing & metrics

Simple real-life example (Understand first — very important for understanding)

• Logging: what happened and when (e.g. "Order 123 created").
• Tracing: one request’s path across services (A → B → C) so you see the full journey.
• Metrics: counts and timings (requests/sec, latency percentiles) to see health and trends.

Real-world idea: with many services you need structured logs, distributed traces (same trace ID across services), and metrics to debug and monitor.

Technical definition

• Logging: structured logs (JSON); include correlation/trace ID so you can group by request.
• Distributed tracing: trace ID + span ID; each service adds a span; see full path and latency (e.g. Jaeger, Zipkin).
• Metrics: counters, gauges, histograms; scrape or push to Prometheus/Grafana; alert on SLOs.

Why it matters

Without observability, microservices are hard to debug and operate. Interviewers expect awareness of logs, traces, and metrics.

Interview tip

Say: "We use structured logging with trace IDs, distributed tracing to follow a request across services, and metrics for latency and errors so we can debug and meet SLOs."

When to use microservices vs monolith

Simple real-life example (Understand first — very important for understanding)

• Start with one team and one product: one place (monolith) is simpler. When you have many teams, different scaling needs, or need to deploy parts independently, splitting into services can help—but adds coordination and complexity.
• Don’t split too early; split when boundaries and benefits are clear.

Real-world idea: use a monolith (or modular monolith) until you feel real pain (scale, release cadence, team size). Then extract services along clear domain boundaries.

Technical definition

• Monolith: simpler ops, one deploy, ACID in one DB; good for small teams and early product. Con: scaling is all-or-nothing, coupling can grow.
• Microservices: independent deploy and scale, team ownership, tech diversity. Con: distributed complexity, eventual consistency, network and ops overhead.
• Consider: modular monolith first; split when you have clear bounded contexts and a need for independence.

Why it matters

Interviewers want to hear a balanced view: when microservices help and when they don’t.

Interview tip

Say: "I’d start with a monolith or modular monolith and introduce microservices when we need independent scaling or deployment, or multiple teams. I’d avoid microservices just for the sake of it."