ArchitectureIntermediate

Microservices

Architectural style where an application is built as a collection of small, independent services, each running its own process and communicating through APIs.

Pronunciation

/ˌmaɪ.krəʊˈsɜː.vɪs.ɪz/
"MY-kroh-SUR-vis-iz"
Listen on:Forvo

What is it

Microservices are a software architecture style where an application is divided into small, independent, specialized services. Each service:

  • Does one thing well (single responsibility principle)
  • Has its own database or storage
  • Communicates with other services via APIs
  • Can be deployed, scaled, and updated independently

Monolith vs. Microservices

Monolithic Architecture (traditional)

┌─────────────────────────────────────────┐
│            MONOLITHIC APP               │
│  ┌──────────┐ ┌──────────┐ ┌─────────┐ │
│  │  Users   │ │  Orders  │ │Payments │ │
│  └──────────┘ └──────────┘ └─────────┘ │
│  ┌──────────┐ ┌──────────┐ ┌─────────┐ │
│  │Inventory │ │ Reports  │ │Notific. │ │
│  └──────────┘ └──────────┘ └─────────┘ │
│          ↓   Single database   ↓        │
└─────────────────────────────────────────┘

Problem: if you need to update the Payments module, you must redeploy the entire application.

Microservices Architecture

[Users Service] ←→ [Orders Service] ←→ [Payments Service]
      ↓                   ↓                    ↓
 [Users DB]          [Orders DB]          [Payments DB]

Each service is updated, scaled, and deployed separately.

Advantages

Advantage Why it matters
Independent scaling If Payments has heavy load, scale only Payments — not the whole app
Technology per service Users in Node.js, Reports in Python, Payments in Java
Isolated failures If Notifications fails, Orders keeps working
Independent teams Each team owns their service, deploys without massive coordination
Frequent deployments Changing one service doesn’t affect the others

Challenges

Microservices aren’t free. They introduce complexity:

  • Inter-service communication: How do they talk to each other? What happens if one fails?
  • Distributed data: maintaining consistency across multiple databases is hard
  • Observability: tracing an error that passed through 5 services requires specific tooling
  • Operational overhead: each service needs its own CI/CD, monitoring, logs

That’s why microservices are better suited for complex systems with large teams.

When It Makes Sense

✅ Microservices work well when:

  • The system is large and complex, with clearly distinct business domains
  • Multiple teams work in parallel on different parts
  • Parts of the system have very different scaling requirements
  • You need high availability (partial failures are acceptable)

❌ A well-structured monolith is better when:

  • The team is small
  • The system is in early stage or pivoting frequently
  • The distributed complexity would outweigh the benefits

Companies Using Microservices

  • Netflix: migrated from a monolith to a cloud microservices architecture, cited as an early reference case for the pattern
  • Amazon: adopted a service-oriented architecture early, with teams owning services such as cart, checkout, or recommendations
  • Uber: went from a monolith to around 2,200 critical microservices and in 2020 reorganized them by domain (DOMA) to reduce complexity
  • API - The communication channel between microservices
  • Docker - Each microservice typically runs in its own container
  • DevOps - The practices needed to successfully operate microservices
  • REST - The most common style for inter-microservice communication

Additional Resources:

Related articles

All terms