Architecture Intermediate

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 Cambridge

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

AdvantageWhy it matters
Independent scalingIf Payments has heavy load, scale only Payments — not the whole app
Technology per serviceUsers in Node.js, Reports in Python, Payments in Java
Isolated failuresIf Notifications fails, Orders keeps working
Independent teamsEach team owns their service, deploys without massive coordination
Frequent deploymentsChanging 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 (50+ endpoints)
  • 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 (< 5 developers)
  • The system is in early stage or pivoting frequently
  • The distributed complexity would outweigh the benefits

Companies Using Microservices

  • Netflix: over 1000 microservices for global streaming
  • Amazon: cart, checkout, recommendations — each is a separate service
  • Uber: split its monolith into services by transport type and city
  • [[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 protocol for inter-microservice communication

Additional Resources:

All terms