How should service granularity evolve over the lifetime of a system, and what concrete signals tell an engineering organization it's time to split a service apart or merge services back together?

## Granularity is a living decision Service granularity is not a property you get right once at design time and then leave alone — it's a decision that should be revisited as three things change over a system's life: 1. **Traffic and scaling patterns** — a feature that was low-traffic at launch can become the system's dominant cost center. 2. **Team structure** — teams split, merge, and reorganize, and service boundaries that don't track team boundaries create friction. 3. **Business requirements** — a capability that used to be a minor feature can become a standalone product needing its own release cadence, compliance boundary, or even separate vendor/SLA. Treating granularity as fixed leads to architecture that's well-matched to the org and business of two years ago and increasingly mismatched to the org and business of today — this mismatch is exactly what produces the macroservice and nanoservice smells covered elsewhere on this topic. ## The signals that a boundary has gone stale Detecting that a boundary has gone stale requires concrete signals, not intuition. **On the 'should split' side:** - a **change-coupling analysis** (mining version-control history for files/modules that are almost always modified together across many commits) can reveal that a chunk of a service's codebase has effectively stopped changing in lockstep with the rest, meaning it's already behaving like a separate capability even though it's still packaged together - **incident postmortems** are another rich signal — repeatedly seeing 'an unrelated change in module X caused an outage in module Y' or 'we couldn't hotfix Y because it required a coordinated release with X's owning team' points directly at a coupling boundary that should become a service boundary **On the 'should merge' side**, the signals mirror the chattiness and macroservice discussions: - a consistently high ratio of cross-service network calls to actual business logic performed - deploy logs showing two services are released together in lockstep on nearly every change - on-call data showing incidents in one service are almost always resolved by also touching the other ## The mechanism matters as much as the decision Once a signal justifies a change, the mechanism matters as much as the decision. A big-bang rewrite — freezing feature work to carve a new service out of an existing one in one large migration — carries high risk: it takes the team out of shipping value for an extended period, and any mistake in the new boundary only surfaces after the full cutover, when it's expensive to reverse. The industry-standard alternative, the **strangler fig pattern** (named by Martin Fowler after the strangler fig vine that grows around a host tree and gradually replaces it), routes traffic through a facade or proxy and incrementally moves individual capabilities behind that facade into the new service one at a time, while the old code path keeps serving whatever hasn't been migrated yet. This keeps the system releasable and rollback-able throughout the migration — if the new piece misbehaves, traffic for that specific capability can be routed back to the old implementation without touching anything else. ## The cost of a change in progress Splitting-in-progress carries real interim cost; merging-in-progress carries a mirrored cost. | Direction | What you pay while it is under way | |---|---| | Splitting-in-progress | for a while you have to maintain both the old and new code paths, keep data consistent across the boundary being carved (often via dual-writes or change-data-capture events during the transition), and carry the cognitive overhead of a boundary that's half-drawn | | Merging-in-progress | consolidating two services' data models usually means one has to be treated as canonical and the other's data migrated or reconciled, and any external consumers of the service being absorbed need a compatibility period (often via an adapter or the same facade approach) before they can be pointed at the new consolidated API | Neither direction is free, which is exactly why granularity changes shouldn't be undertaken on a hunch — the concrete detection signals exist precisely to make sure the migration cost is justified by a real, evidenced problem rather than an aesthetic preference for 'cleaner' boundaries. ## Granularity review as an ongoing practice A well-documented real pattern is large platform companies' publicized experience of extracting high-traffic subsystems (e.g., checkout, inventory) out of a larger core service specifically once those subsystems' independent scaling needs and team ownership became clear from production data — and, conversely, some companies have published accounts (Segment's widely discussed 2018 write-up about consolidating a large microservice fleet is a commonly cited example) of deliberately merging services back together after finding the operational overhead of an over-decomposed service fleet exceeded the independence benefit for their actual team size and traffic. The organizational takeaway is that a mature engineering org should treat granularity review as an ongoing practice — periodically revisiting service boundaries using change-coupling and incident data, similar to how it revisits capacity or dependency-upgrade needs — rather than as a decision made once at a system's inception and never revisited.