Microservices
Microservices is an architectural style where a single application is composed of many small, independently-deployable services, each owning its own data and communicating over the network. Services are organised around business capabilities and typically owned end-to-end by small autonomous teams. The trade-off is operational complexity (many deployables, network failure modes, distributed tracing) in exchange for independent deployability and team autonomy.
The term was popularised around 2014 by Martin Fowler and James Lewis. The honest assessment after a decade of industry experience: microservices solve a specific set of problems (team-scale deployment coordination, polyglot stacks, independent scaling of subsystems) and create their own (operational overhead, distributed-systems failure modes, data-consistency complexity). Most teams that adopted microservices for small applications retreated to 'modular monolith' — a single deployable with clean internal boundaries. The deciding factor is usually team size and deployment coordination cost, not technical scale. Stride's research finds: teams under ~30 engineers rarely benefit from microservices; teams over ~150 rarely succeed without them.
Related terms
- Bounded context
A bounded context is the boundary within which a particular domain model — its terms, rules, and invariants — is consistent and authoritative.
- Conway's Law
Conway's Law, formulated by Melvin Conway in a 1968 paper, states that any system's design mirrors the communication structure of the organisation that built it.
- Service mesh
A service mesh is an infrastructure layer for service-to-service communication, typically implemented as a sidecar proxy (Envoy, Linkerd-proxy) running alongside each service.