When to use microservices (and when not to) - System Design Guide

Problem Statement

Monolithic applications become hard to maintain and scale as they grow. When many teams work on the same codebase, changes can cause unexpected bugs and slow down releases. Also, scaling the entire app for a small part that needs more resources wastes effort and money.

Solution

Microservices break the application into small, independent services that focus on specific business functions. Each service can be developed, deployed, and scaled separately, allowing teams to work independently and scale only what is needed. This reduces complexity and improves fault isolation.

Architecture

Service A

→Service B

↓

Database A

This diagram shows independent microservices communicating with each other and managing their own databases, illustrating separation and independent scaling.

Trade-offs

✓ Pros

→

Enables independent development and deployment by different teams.

→

Improves fault isolation; failure in one service doesn't crash the whole system.

→

Allows scaling only the services that need more resources, saving costs.

→

Supports technology diversity; teams can choose the best tools per service.

✗ Cons

→

Increases operational complexity with many services to monitor and manage.

→

Requires robust inter-service communication and data consistency handling.

→

Can lead to duplicated effort and data if not carefully designed.

Use microservices when your application has multiple distinct business domains, requires independent scaling, or when multiple teams need to work in parallel without blocking each other. Typically beneficial when user traffic exceeds thousands of requests per second or when deployment speed and fault isolation are critical.

Avoid microservices if your application is small, simple, or has a single team managing it. If your traffic is low (under a few hundred requests per second) or you need rapid initial development, the overhead of microservices can slow you down and add unnecessary complexity.

Real World Examples

Netflix

Split their streaming platform into microservices to allow independent scaling and rapid deployment of new features without downtime.

Amazon

Decomposed their monolithic retail platform into microservices to enable teams to innovate independently and scale services like search and recommendations separately.

Uber

Uses microservices to handle different domains like trip management, payments, and user profiles, allowing fault isolation and independent scaling.

Alternatives

Monolithic Architecture

All functionality is built into a single deployable unit without service boundaries.

Use when: Choose monolith when the application is small, teams are small, and rapid initial development is needed.

Modular Monolith

Application is a single deployable unit but internally organized into clear modules with strict boundaries.

Use when: Choose modular monolith when you want clear code separation without the operational complexity of microservices.

Serverless Architecture

Breaks functionality into small functions triggered by events, abstracting server management.

Use when: Choose serverless when you have event-driven workloads with unpredictable traffic and want to minimize infrastructure management.

Summary

Microservices break large applications into smaller, independent services to improve scalability and team autonomy.

They add operational complexity and require careful design of communication and data management.

Use microservices when your system is large, complex, or needs independent scaling; avoid them for small or simple apps.