Service Granularity

The Sizing Question

 "micro" services mislead: the goal was never SMALL,
 it was INDEPENDENTLY VALUABLE.

 too fine (nano-service fever):
   40 services where 6 suffice → every feature = cross-service
   choreography, latency tax, ops sprawl, cognitive overload

 too coarse:
   "services" sharing deploy trains and databases →
   distributed monolith with worse debugging

 RIGHT-SIZED: one bounded context per service;
 a team can own several; nobody owns twenty.

Signals You’re Too Fine

 □ CHANGE AMPLIFICATION: user-facing features consistently
   touch 5+ services ("add coupon" = orders+billing+cart+
   notifications+analytics PRs)
 □ CHATTINESS: services calling each other many times per
   single logical operation (network as function-call tax)
 □ ANEMIC SERVICES: CRUD shells with no real logic
 □ DEPLOY TRAINS: lockstep releases despite "independence"
 □ ONBOARDING PAIN: new engineers need the MAP to understand
   any flow; nobody holds the system in their head

 fixes: MERGE along change-coupling lines. consolidation
 is not failure — it's calibration to reality.

Signals You’re Too Coarse

 □ DEPLOY COUPLING: teams wait on each other's release trains
 □ SCALE MISMATCH: one hot component forces scaling the whole unit
 □ FAILURE COUPLING: report-generation bug takes checkout down
 □ OWNERSHIP FOG: "who owns this code?" has three answers
 □ TECHNOLOGY LOCKSTEP: need for search/vector/specialized
   storage blocked by the shared monolith's choices

 fixes: EXTRACT along load/ownership/churn seams —
 strangler-fig machinery applies.

The Sizing Heuristics

Heuristic	Test
Bounded context	one language, one model inside
Team calculus	each team ≤ ~2-3 services it knows deeply
Change independence	features touch ≤1-2 services typically
Scale profile	meaningfully different curves → separate
Failure blast	risky components isolated deliberately
Data ownership	exactly one writer per dataset

 the TEAM heuristic deserves weight (inverse Conway):
 architecture mirrors org structure eventually anyway —
 design boundaries WITH that gravity rather than against it.

Granularity Is a Dial, Not a Decision

 start coarser; split on EVIDENCE:

 v1:  [orders+cart] [catalog+search] [users+auth] [payments]
      ← few cohesive services ship value fast →

 evidence accumulates: search load profile diverges wildly →
 split [search] out. payments needs compliance isolation →
 extract. cart churns 10× faster than orders → separate.

 merging back is equally legitimate when splits disappoint.
 teams that NEVER adjust granularity sized it once
 by fashion, not by feedback.

 the metric to watch over time: average number of services
 touched per product feature. trending UP without business
 cause = fragmentation debt accruing.

Interview Framing

“How many services would you create for this domain?” scored shape: refuse the absolute-number framing, present heuristics table, propose a CONSERVATIVE v1 with merge/split triggers defined, cite change-amplification as the fragmentation metric, note org-gravity. The graded skill is CALIBRATED judgment under uncertainty — candidates who promise 30 services on day one fail the same way candidates who promise one giant service do.