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