Skip to main content

Microservices Architecture

TL;DR

Microservices: Break monolith into small, independent services. Benefits: Independent deployment, technology flexibility, team autonomy. Challenges: Distributed complexity, data consistency, network latency. When to use: Large teams, need to scale parts independently.

Why This Matters

In interviews: Shows you understand service boundaries, communication patterns, and trade-offs vs monoliths.

Core Concepts

1. Monolith vs Microservices

AspectMonolithMicroservices
DeploymentAll-or-nothingIndependent per service
ScalingScale entire appScale specific services
TechnologySingle stackPolyglot (mix languages)
ComplexitySimpleDistributed system complexity
Team structureSingle teamTeam per service
DataShared databaseDatabase per service

2. Service Communication

Synchronous (HTTP/gRPC)

Pros: Simple, immediate response
Cons: Tight coupling, cascading failures

Asynchronous (Message Queue)

Pros: Decoupled, resilient
Cons: Eventual consistency, harder to debug

3. API Gateway Pattern

Responsibilities:

  • Routing: Forward requests to correct service
  • Authentication: Verify JWT tokens
  • Rate limiting: Prevent abuse
  • Response aggregation: Combine multiple service calls
  • Protocol translation: REST → gRPC

Popular gateways: Kong, AWS API Gateway, NGINX, Envoy

4. Service Mesh

Purpose: Handle service-to-service communication (retries, circuit breakers, observability).

Example (Istio):

  • Sidecar proxy (Envoy) next to each service
  • Automatic retries, circuit breakers
  • Distributed tracing (automatic)
  • Mutual TLS (service-to-service encryption)

5. Data Management

Database per service (best practice):

User Service → User DB
Order Service → Order DB

Cross-service queries:

  • API composition: User service calls Order service
  • CQRS: Separate read/write models
  • Event sourcing: Rebuild state from events

Common Interview Questions

Q1: "When would you use microservices vs monolith?"

Answer: Use microservices when:

  • Large team (greater than 20 engineers)
  • Need independent deployment
  • Scale parts independently
  • Different tech stacks per service

Use monolith when:

  • Small team (less than 10 engineers)
  • Simple domain
  • Startup (iterate fast)

Q2: "How do microservices communicate?"

Answer:

  • Synchronous: HTTP/REST, gRPC (tight coupling)
  • Asynchronous: Message queues (loose coupling)
  • Choose async for: Events, background jobs
  • Choose sync for: User-facing requests needing immediate response

Q3: "How do you handle distributed transactions?"

Answer:

  • Avoid if possible (design services to be independent)
  • Saga pattern: Choreographed compensation (see Chapter 23)
  • Eventual consistency: Accept temporary inconsistency

Quick Reference

Benefits: Independent deploy, scale, tech stack
Challenges: Complexity, consistency, debugging

Patterns:

  • API Gateway (single entry point)
  • Service mesh (inter-service communication)
  • Database per service (data ownership)

Next: Data Pipelines - ETL, streaming, batch processing.