Microservices

Theory

Microservices decompose an application into independently deployable services bounded by business domains (DDD). Each service owns its data, codebase, and release cycle — enabling team autonomy and technology heterogeneity at the cost of distributed system complexity.

Decompose by domain capability (orders, payments, inventory) not by technical layer (all DBs together). Services communicate via well-defined APIs. Avoid distributed monolith — services that must deploy together defeat the purpose.

Synchronous communication (REST, gRPC) is simple and request-response oriented — caller blocks until response. Good for queries needing immediate answers. Creates runtime coupling: callee failure propagates to caller without circuit breakers.

Asynchronous communication (message queues, event buses) decouples producers and consumers in time. Events announce facts ("OrderPlaced") — multiple subscribers react independently. Enables eventual consistency and load leveling but harder to debug and trace.

Distributed transactions across services are avoided. Saga pattern coordinates local transactions with compensating actions on failure (e.g. cancel payment if shipment fails). Choreography (events) vs orchestration (central coordinator) — choreography scales better; orchestration is easier to reason about.

Two-phase commit (2PC) provides atomicity across databases but blocks on coordinator failure and doesn't scale — rarely used in microservices. Prefer sagas with idempotent consumers and outbox pattern for reliable event publishing.

Service mesh (Istio, Linkerd) injects sidecar proxies handling mTLS, retries, timeouts, traffic splitting, and observability without app code changes. Circuit breaker pattern stops calling failing services after threshold — fail fast instead of cascading timeouts.

Distributed tracing (OpenTelemetry, Jaeger, Zipkin) correlates requests across services via trace IDs propagated in headers. Essential for debugging latency in microservice call chains. Without tracing, a 2s API response hiding five 400ms serial calls is invisible.

Architecture Diagram

Users / clients
         |
  Microservices
         |
  Core services
         |
  Data + observability

Examples

// order.proto
service OrderService {
  rpc CreateOrder(CreateOrderRequest) returns (Order);
  rpc GetOrder(GetOrderRequest) returns (Order);
}

// Client calls with deadline
ctx, cancel := context.WithTimeout(ctx, 500*time.Millisecond)
defer cancel()
order, err := client.CreateOrder(ctx, &pb.CreateOrderRequest{...})

// Order service publishes
publish("OrderPlaced", { orderId, amount })

// Payment service consumes, publishes
on("OrderPlaced") -> charge() -> publish("PaymentCompleted")
on("PaymentFailed") -> publish("PaymentFailed")

// Order service compensates
on("PaymentFailed") -> cancelOrder(orderId)

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: payment-cb
spec:
  host: payment-service
  trafficPolicy:
    connectionPool:
      tcp: { maxConnections: 100 }
      http: { http1MaxPendingRequests: 50 }
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 60s

Interview Questions

Best Practices

• Draw service boundaries around team ownership and data — not around technical layers (never a "database service" for everything).
• Prefer async events for cross-domain workflows — synchronous chains of 5+ services create fragile latency multiplication.
• Implement circuit breakers and timeouts on every outbound call — default infinite wait hangs thread pools cluster-wide.
• Use idempotency keys on write APIs — retries are inevitable in distributed systems.
• Adopt distributed tracing (OpenTelemetry) from day one — debugging cross-service failures without trace IDs is guesswork.
• Design for independent deployability — if two services must ship together, they are not separate services yet.

Common Mistakes

• Splitting monolith by technical layer (API service, DB service) — creates chatty network calls without domain isolation.
• Synchronous chains for checkout/payment — one slow service blocks the entire user request path.
• No schema versioning on events — producers upgrade and break all consumers simultaneously.
• Shared database between services — couples schemas and prevents independent deployment.
• Distributed monolith — microservices repo structure but everything deployed as one unit.

Trade-off Analysis

Microservices improves service boundaries, api contracts, operational complexity. but adds operational and cognitive complexity — justify with load and team size.

Favor simplicity until metrics (p99 latency, error rate, cost) prove the pattern necessary.

Every redundancy layer trades capital/operational cost for availability — align with explicit SLO targets.

Document accepted inconsistency windows and recovery behavior before production cutover.

Cheat Sheet

Practical Exercises