Microservices
MY-kroh-SUR-vih-sez
An architecture where an application is built as a collection of small, independent services.
Microservices is an architectural pattern where an application is decomposed into small, independent services that communicate over a network. Each service owns its own data, runs its own process, and can be deployed independently. A payments service, a user service, and a notification service each run separately.
The appeal is independence. Teams can develop, deploy, and scale each service without coordinating with every other team. The payments team can ship a fix without waiting for the user team's sprint to end. Each service can use the technology best suited to its job.
The cost is complexity. Instead of one application to deploy, monitor, and debug, you have dozens or hundreds. Network calls replace function calls. Distributed transactions replace database transactions. Microservices trade application complexity for operational complexity.
Examples
A monolith is decomposed into services.
An e-commerce platform separates into five services: catalog, cart, payments, shipping, and notifications. Each has its own database and deployment pipeline. The payments team ships twice daily without affecting the catalog. But debugging a failed order now requires tracing across all five services.
A startup chooses microservices too early.
A 5-person startup builds 12 microservices before finding product-market fit. They spend 60% of engineering time on infrastructure: service discovery, distributed tracing, API gateways, and inter-service communication. A monolith would have let them iterate on the product 3x faster.
A service scales independently.
During Black Friday, the payment service gets 10x normal traffic while the user profile service stays flat. With microservices, the team scales only the payment service (adding more instances) without scaling everything else. Cost-efficient and targeted.
In practice
Read more on the blog
Frequently asked questions
When should a company adopt microservices?
When the monolith is genuinely slowing down multiple teams: deployments require coordination across teams, a change in one area breaks another, and scaling requires scaling everything. Most companies under 50 engineers are better served by a well-structured monolith.
How many microservices should a team own?
A team of 5-8 engineers can typically own 3-5 services effectively. More than that and operational burden (monitoring, on-call, deployments) crowds out feature development. If a team owns 15 services, some are not getting the attention they need.
Related terms
A single, unified application where all code runs in one process and deploys as one unit.
Application programming interface: a defined way for software programs to communicate with each other.
Lightweight, portable packages that bundle application code with all its dependencies.
An open-source system for automating the deployment, scaling, and management of containerized applications.
A design pattern where systems communicate by producing and consuming events instead of direct calls.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.