SDI.
All Concepts
Systemsarchitecturedecouplingservice-meshcontainerskubernetesmonolithDDDbounded-context

Microservices Architecture

Microservices architecture structures an application as a collection of small, independently deployable services, each owning its own data and communicating over well-defined APIs.

In a microservices architecture, a large application is decomposed into small, loosely coupled services that can be developed, deployed, and scaled independently. Each service owns its own database (no shared DB), communicates via APIs (REST, gRPC, or async messaging), and is typically deployed in containers orchestrated by Kubernetes. The main benefits are independent deployability, technology diversity, and team autonomy. The main costs are distributed systems complexity, operational overhead, and data consistency challenges.

Tradeoffs

Strengths

  • Independent deployability: Change and deploy one service without affecting others.
  • Team autonomy: Small teams own services end-to-end, enabling faster development.
  • Technology diversity: Each service can use the best language/framework for its domain.
  • Granular scaling: Scale only the services that are bottlenecks.
  • Fault isolation: A failure in one service doesn't necessarily bring down the whole system.
  • Organizational alignment: Conway's Law — system architecture mirrors team structure.

Weaknesses

  • Distributed systems complexity: Network failures, latency, partial failures, and data inconsistency.
  • Operational overhead: More services to deploy, monitor, debug, and maintain.
  • Data consistency challenges: No ACID across services; eventual consistency requires careful design.
  • Testing difficulty: Integration and end-to-end testing across services is significantly harder.
  • Network latency overhead: Inter-service calls add milliseconds compared to in-process calls.
  • Infrastructure cost: Service mesh sidecars, API gateways, message brokers, and observability tools all consume resources.

Likely Follow-Up Questions

  • How do you handle distributed transactions across microservices?
  • When should you start with a monolith vs. microservices?
  • How do you handle service discovery in a microservices architecture?
  • What is the saga pattern and when would you use choreography vs. orchestration?
  • How do you implement distributed tracing across microservices?
  • What are the failure modes in microservices and how do you design for resilience?

Source: editorial — Synthesized from Martin Fowler's microservices writings, Netflix/Uber/Spotify engineering blogs, and DDD literature by Eric Evans.

Command Palette

Search for a command to run...