Microservices
An architectural style that structures an application as a collection of small, independent services.
Detailed Explanation
Each microservice handles a specific business function (e.g., Auth, Payments, Inventory) and communicates via lightweight protocols like HTTP or gRPC. This allows teams to develop, deploy, and scale parts of the application independently. While it increases organizational speed, it introduces significant operational complexity in networking and data consistency.
Quick Summary
Microservices split a system into small, independently deployable services that own their data and communicate over the network. The win is team autonomy and isolated scaling; the cost is distributed-systems complexity that didn't exist in a monolith.
Key Takeaways
- Each service has its own datastore, sharing a database across services defeats the purpose.
- Synchronous calls (HTTP, gRPC) couple services at runtime; async messaging (Kafka, NATS) decouples them.
- Observability (tracing, structured logs, metrics) goes from nice-to-have to mandatory.
- Service-per-team is a common pattern (Conway's Law), boundaries follow org structure as much as technical concerns.
- Microservices solve organizational problems; if you have one team and one codebase, you probably want a modular monolith instead.
When to use it
- Large engineering orgs where teams need to ship independently without coordinating releases.
- Workloads with wildly different scaling profiles (auth: steady, video transcoding: burst).
- Polyglot stacks where different services benefit from different languages or runtimes.
- Acquired companies whose existing systems can stay separate behind a common API gateway.
Common Mistakes
- Starting greenfield with microservices before you understand the domain, boundaries are wrong and refactoring across services is painful.
- Distributed monolith: separate deployables that must be released together because they share schemas or chatty sync calls.
- Sharing a database across services so a schema change blocks every service at once.
- Underinvesting in platform tooling (CI templates, service mesh, observability), every team reinvents the wheel.
Microservices, Frequently Asked
When should I move from a monolith to microservices?
When team coordination costs exceed the cost of running and operating multiple services, usually multi-team orgs, not small startups. Until then, a well-modularized monolith ships faster and breaks less.
How small is a microservice?
Small enough that one team owns it end-to-end, big enough that it represents a coherent capability. "One service per database table" is too small and produces a distributed monolith.
Microservices vs. serverless functions?
Different axes. A microservice is an architectural boundary; serverless is a deployment model. You can run microservices on VMs, containers, or as functions, the architectural decision is independent of how each service is hosted.