Microservices

Microservices

Microservices split an app into small services that each own one business area and its data, and that can each be released, scaled and fixed on their own. The price is that every call between them crosses the network — it's slower, it can fail, and each extra service a request has to wait on adds its own delay and its own chance of failure. Running many services also needs serious automation and monitoring. They pay off for large teams on a well-understood domain; for a small team or a young product they're mostly cost.

Use when

Many teams on a large, well-understood domain whose parts need separate releases, scaling or failure isolation · An organization that already has automated provisioning, deployment and monitoring

Avoid when

A small team or a young product whose boundaries are still moving — start with a (modular) monolith · Parts that call each other constantly or must change data together in one transaction · Without automation and monitoring in place — the services become a distributed monolith that is also hard to run

Trade-offs

Independent release, scaling and failure isolation, in exchange for network calls that are slower and can fail · Each synchronous hop adds latency and multiplies down availability; async messaging and breakers win some of it back · Each team owns its data, so changes across services lose one ACID transaction and need eventual consistency · Many pipelines, discovery, tracing and versioning to run — an operational premium paid before the benefits

Requires

Service boundaries, Circuit breaker, Async work with a queue