A team packages their entire application — web UI, order processing, and inventory logic — into one JAR file that gets built by one CI pipeline and deployed to production as a single unit. What operational advantage does this single-artifact deployment give the team day to day, and what's the corresponding cost when only the inventory logic needs to change?

## What "single deployable unit" means 'Single deployable unit' means the build pipeline produces exactly one artifact — a JAR, a WAR, a Docker image wrapping one binary — and that one artifact is what gets versioned, tested, promoted through environments, and rolled back if something goes wrong. Concretely: 1. `git commit` triggers one CI job. 2. That job runs one test suite and produces one version-tagged artifact (say `app-v482.jar`). 3. That artifact is deployed to every instance behind the load balancer. 4. If `v482` is broken the rollback is simply redeploying `v481` everywhere. There's exactly one thing to reason about at deploy time. ## What the single artifact buys This buys real **operational simplicity** relative to a distributed alternative. - There's **no service registry** to keep consistent. - There's **no need to version an internal API** between two independently deployable pieces — the inventory 'module' and the order 'module' are compiled together, so a breaking change to inventory's internal method signature is caught by the compiler immediately, not discovered at runtime by a mismatched service contract. - There's **no need to decide deploy order** across a dependency graph of services, and no need to run canary rollouts across a fleet of different services with different versions in flight. - **Infrastructure is simpler too** — one runtime, one process type to autoscale, one set of health checks and metrics dashboards. For a small team this is a genuine, not merely nostalgic, advantage: less to build, less to operate, fewer moving parts that can be individually misconfigured. ## The cost is the direct mirror of the benefit The cost is structural, not incidental, and it's the direct mirror of the benefit: **because there is one artifact, there is one unit of change.** - If the inventory team fixes a one-line bug, the artifact that ships contains that fix bundled with whatever the UI team and the order-processing team happen to have merged since the last release — code they may not have finished testing, or may have deliberately left behind a feature flag for later. - The entire application's test suite has to pass, end to end, before any part of it can go out, which means test suite runtime and flakiness become a shared tax the whole organization pays on every release, not just the team whose code actually changed. As the codebase and headcount grow, this shows up very concretely: - **Release cadence slows down** — weekly, then biweekly, then feature-flagged 'dark' releases just to decouple the deploy event from the feature's actual availability. - **'Merge freeze' periods** appear before releases to stabilize the shared artifact. - **One team's broken build or failing test** literally blocks every other team's ability to ship anything, including urgent fixes unrelated to the breakage. ## How it shows up in production, and socially In production this failure mode shows up as deploy velocity metrics (deploy frequency, lead time for changes — the DORA metrics) plateauing or regressing even as the team grows, which is often the first hard signal that a monolith's deployment model has become the bottleneck rather than the codebase's raw complexity. It also shows up socially: - Teams start negotiating over shared release windows. - A 'release manager' role emerges just to coordinate who's allowed to merge before a cut. - Hot-fixing production for one team's critical bug means either a full rebuild-and-redeploy of the entire artifact (slow, and risks pulling in someone else's half-finished change) or a separate emergency branch-and-cherry-pick process that adds its own risk. ## The Amazon instance of this trade-off A well-known real-world instance of exactly this trade-off is Amazon's own early monolith (internally called Obidos): as Amazon's single deployable grew, build times, test suite runtime, and coordination overhead across hundreds of engineers sharing one release train became a widely cited internal motivation for eventually decomposing into independently deployable services — not because the single-artifact model is wrong, but because the cost side of that trade-off (shared release train, shared test suite, coupled deploy cadence) scales worse with team size than the benefit side (deployment simplicity) scales well. Smaller teams and smaller codebases routinely make the opposite, and often correct, call: the single-artifact simplicity is worth more than the coupling costs until team size or release-frequency needs actually create pain.