Microservices architecture structures an application as a collection of small, independent services that communicate over APIs. Each service owns its data, deploys independently, and can use different technologies. Netflix, Uber, and Amazon run thousands of microservices.

How Microservices Works

An e-commerce monolith has one codebase for users, orders, payments, and inventory. In microservices: each is a separate service with its own database. Deploy the payment service without touching inventory. Scale the order service independently during sales. If the recommendation service crashes, checkout still works.

Microservices add complexity: distributed transactions, network latency, service discovery, observability across services. Start with a monolith, extract services only when you have a clear reason — team boundaries, scaling needs, or deployment independence.

Why Developers Use Microservices

Microservices solve organizational problems (multiple teams working independently) and scaling problems (scale individual services). They don't solve code quality problems. A bad monolith becomes bad microservices plus a distributed systems headache.

Key Concepts

  • Service Boundaries — Each microservice owns a specific business capability and its data — users, orders, payments
  • Independent Deployment — Deploy, scale, and update services independently — no coordinated releases
  • API Communication — Services communicate via HTTP/REST, gRPC, or message queues — no shared databases
  • Data Isolation — Each service owns its database — no direct database queries between services
  • Service Discovery — How services find each other — DNS, service registries (Consul), or platform-native (Kubernetes)
  • Distributed Tracing — Track requests across multiple services — Jaeger, Zipkin, OpenTelemetry

Kubernetes Microservice Deployment

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-service
  template:
    spec:
      containers:
      - name: order-service
        image: myapp/order-service:v2.1
        ports:
        - containerPort: 8080
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: order-db-secret
              key: url

Frequently Asked Questions

When should I use microservices?

When you have multiple teams that need to deploy independently, when specific parts of the app need different scaling, or when you need technology diversity. Not for small teams or new projects — start with a monolith.

Microservices vs monolith?

Monolith for small teams, new projects, and simple domains. Microservices for large organizations, complex domains, and independent scaling needs. The monolith-first approach is recommended by most experts.

How small should a microservice be?

Sized by team ownership, not lines of code. A service should be owned by one team and represent one business capability. If two services always deploy together, merge them.