Microservices Style

## What the property actually says **Independent deployability** is the property that a single microservice's code can be changed, tested, and pushed to production by its owning team without requiring any other service to be redeployed at the same moment, and without breaking any other service still running its previous version. Mechanically this rests on three things: 1. **Its own source repository** or clearly separated module. 2. **Its own build and release pipeline** that produces a versioned deployable artifact -- a container image, a JAR, a Lambda package. 3. **Its own runtime process** or instance, separate from any other service's process. When a team wants to change how their service computes a discount, add a field, or fix a bug, they change only that artifact, run it through their own pipeline, and roll it into production, while every other service keeps running whatever version it was already running. ## Why this is the defining trait The reason this property is the defining trait of the microservices style, more than 'small size' or 'uses HTTP,' is that essentially every other characteristic commonly attributed to microservices exists to protect it. - **Bounded contexts.** Organizing services around bounded contexts -- boundaries within which a specific business model and vocabulary stay consistent -- gives each service a coherent piece of business capability that can evolve on its own timeline, rather than a technical slice that every feature touches and that therefore forces every team to coordinate. - **Its own data store.** Each service owning its own data store means a service's internal schema can change without a migration script that has to run in lockstep across the whole estate. - **Narrow, versioned interfaces.** Favoring narrow, versioned interfaces between services means the internals behind that interface are free to change as long as the interface's contract holds. Strip all of that away and what remains is just a system split into physically separate processes that still have to be released together -- which does not deliver the organizational benefit microservices exist for. ## The trade-off The trade-off is real and worth naming honestly. A monolith gives you: - **one build**; - **one test suite** that can validate the whole system end to end in one run; - **one deployment** to roll back if something goes wrong; - and **no network calls** between pieces that changed together. Microservices give up all of that in exchange for letting many teams -- often organized along the same lines as the services themselves -- ship independently at their own cadence, with a failure or slow deploy in one team's service not blocking every other team's release. That benefit shows up as **organizational scaling**, not as a technical performance win; a small team building a small product does not usually need it. What it costs is operational: - more independently moving **artifacts to version, deploy, and monitor**; - the need for **contract testing or careful API versioning**, so that one team's deploy doesn't silently break a service still calling the old shape of a response; - the loss of a **single atomic 'the whole system works' test**, since verifying correctness now means verifying that the currently-deployed combination of many independently-versioned services behaves correctly together. ## Failure modes Failure modes here tend to be organizational before they're technical. 1. **The distributed monolith.** The most common one is what practitioners call a 'distributed monolith': services are physically separate processes, each with its own repo and pipeline, but two or more of them can only be deployed together because, say, one always expects a database column the other just added, or a shared library version has to move in lockstep across both. Teams get all of the network latency, operational overhead, and debugging difficulty of microservices while getting none of the independent-deployability benefit, because a release still requires a synchronized, coordinated rollout. 2. **Skipping backward-compatibility discipline.** Another failure mode: a service changes its response shape or removes a field and deploys, and every downstream caller still on the old assumption breaks in production, with the failure surfacing far from the change that caused it. ## Where it has played out A concrete, well-known example: Amazon's internal API mandate empowered teams to expose functionality only through service interfaces and to own and deploy their own service independently, which is widely credited with letting the company ship changes to individual pieces of its retail platform without a company-wide release train. Netflix's move off a monolithic architecture to hundreds of independently deployable services is another widely cited case, driven by the same need: many teams shipping many small changes daily without waiting on a shared release process.