A microservice is a small, independent piece of your application that does one thing and runs on its own.

Instead of one big application (a monolith) that handles everything — users, payments, emails, search — you split it into separate services that communicate over APIs.

Monolith vs Microservices

Monolith:
┌─────────────────────────┐
│  Users + Orders + Email  │
│  + Search + Payments     │
│  (one codebase, one DB)  │
└─────────────────────────┘

Microservices:
┌──────────┐  ┌──────────┐  ┌──────────┐
│  Users   │  │  Orders  │  │  Email   │
│  Service │←→│  Service │←→│  Service │
└──────────┘  └──────────┘  └──────────┘
     ↕              ↕
┌──────────┐  ┌──────────┐
│  Search  │  │ Payments │
│  Service │  │  Service │
└──────────┘  └──────────┘

Each service:

• Has its own codebase
• Has its own database
• Can be deployed independently
• Can be written in a different language
• Communicates via HTTP/REST, GraphQL, or message queues

When to use microservices

• ✅ Large team (10+ developers) — teams can own individual services
• ✅ Different parts need different scaling (search gets 100x more traffic than payments)
• ✅ You need to deploy parts independently (update payments without touching users)
• ✅ Different parts need different tech stacks
• ❌ Small team or solo developer — the overhead will slow you down
• ❌ Early-stage startup — you don’t know your domain well enough yet
• ❌ Simple application — a monolith is simpler and faster to build

The honest advice: Start with a monolith. Split into microservices when you feel the pain of the monolith. Most apps never need microservices.

How services communicate

Synchronous (request/response)

• REST API — HTTP calls between services. Simple, widely used.
• gRPC — binary protocol, faster than REST. Popular in Go and Java.

Asynchronous (events)

• Message queues — RabbitMQ, AWS SQS. Service A publishes an event, Service B processes it later.
• Event streaming — Kafka, Redis Pub/Sub. Real-time event processing.

The hard parts

Microservices solve some problems but create new ones:

• Network failures — services go down, networks are unreliable
• Data consistency — no more single database transactions
• Debugging — a request touches 5 services, where did it fail?
• Deployment complexity — you need Docker, Kubernetes, CI/CD
• Monitoring — you need distributed tracing, centralized logging

Essential infrastructure for microservices

Running microservices in production requires tooling that monoliths don’t need:

• Service discovery — services need to find each other. Tools like Consul, Kubernetes DNS, or AWS Cloud Map handle this.
• API Gateway — a single entry point that routes external requests to the right service. Handles auth, rate limiting, and request routing. Nginx or Kong are common choices.
• Distributed tracing — follow a request across multiple services. Jaeger, Zipkin, or Datadog trace requests end-to-end so you can find where latency or errors occur.
• Centralized logging — aggregate logs from all services into one place (ELK stack, Grafana Loki). Without this, debugging is impossible.
• Health checks and circuit breakers — detect when a service is unhealthy and stop sending it traffic. Prevents cascading failures where one broken service takes down everything.

Real-world example

An e-commerce platform might split into:

┌────────────┐     ┌────────────┐     ┌────────────┐
│  Product   │     │   Cart     │     │  Payment   │
│  Catalog   │     │  Service   │     │  Service   │
│  (Node.js) │     │  (Go)      │     │  (Java)    │
└────────────┘     └────────────┘     └────────────┘
       ↕                  ↕                  ↕
┌────────────┐     ┌────────────┐     ┌────────────┐
│  Search    │     │  Shipping  │     │  Email     │
│  (Elastic) │     │  (Python)  │     │  (Node.js) │
└────────────┘     └────────────┘     └────────────┘

Each team owns their service end-to-end: code, database, deployment, and on-call. The product catalog team can deploy 10 times a day without coordinating with the payment team.

FAQ

How small should a microservice be?

A microservice should be small enough that a single team (2-8 people) can own it completely, and it should represent one bounded business domain. If a service requires constant coordination with another service to make changes, they’re probably too tightly coupled and should be merged or the boundary redrawn.

Can microservices share a database?

They shouldn’t. Sharing a database creates tight coupling — changes to one service’s schema can break another service. Each microservice should own its data and expose it only through its API. If services need each other’s data, they request it via API calls or subscribe to events.

How do I migrate from a monolith to microservices?

Start by identifying the most independent, well-bounded piece of your monolith and extract it first. Use the “strangler fig” pattern: route traffic for that domain to the new service while the rest stays in the monolith. Repeat gradually — don’t try to split everything at once, as that almost always fails.

Related: You Dont Need Microservices