Service Boundaries

The Decision Everything Hangs On

 microservices with WRONG boundaries cost more than the
 monolith they replaced:

 too fine:   distributed monolith — every feature touches
             9 services, network latency everywhere,
             change-orchestration hell
 too coarse: distributed monolith's cousin — two services
             that always deploy together

 RIGHT: services that CHANGE INDEPENDENTLY because they
 own cohesive domains.

 boundary-drawing is an ORGANIZATIONAL and DOMAIN skill
 dressed as a technical one.

The Cutting Principles

 1. BUSINESS CAPABILITIES, not technical layers:
    ✗ "user-service, logic-service, data-service" (layers)
    ✓ "orders, inventory, billing, identity" (capabilities)

 2. DOMAIN-DRIVEN alignment:
    one bounded context ≈ one service candidate.
    language cohesion test: does this service have ONE
    meaning for "Order"? two meanings = two contexts.

 3. DATA OWNERSHIP follows boundaries:
    each service owns its tables EXCLUSIVELY;
    others access via API/events. never shared schemas.

 4. TEAM TOPOLOGY fits (inverse Conway):
    a service per team-ownable unit; communication paths
    mirror desired org communication paths.

The Litmus Tests

 proposed boundary passes if:

 □ INDEPENDENT CHANGE: features touching it rarely force
   changes elsewhere ("can billing evolve without orders?")
 □ INDEPENDENT DEPLOY: releases don't require lockstep
 □ INDEPENDENT SCALE: its load profile differs from neighbors
 □ SINGLE LANGUAGE: one ubiquitous language inside
 □ FAILURE ISOLATION: its death degrades, not kills, others
 □ DATA AUTONOMY: owns its storage outright

 failing 2+ tests → redraw before writing code.

Boundary Smells

Smell	Meaning
Services always deployed together	wrong cut
Synchronous chains >2 deep	hidden coupling
Shared database between services	no boundary at all
”Common”/“utils” service	junk drawer forming
Every ticket touches 5+ teams	org-boundary mismatch
Circular service dependencies	contexts not actually separate

 the shared-database smell deserves emphasis:
 two services reading/writing one schema share EVERYTHING —
 schema changes couple them, performance couples them,
 failures couple them. it's one lying service split in two.

Starting Points That Work

 greenfield: START COARSER than instinct suggests.
   3–5 solid services beat 15 speculative ones;
   boundaries refine with real change-pattern evidence.
   
 extraction order when splitting a monolith:
   1. edges with distinct load profiles (search, media)
   2. high-churn domains (fast iteration value)
   3. compliance-isolated pieces (payments)
   leave stable core last — strangler-fig lessons apply.

Interview Framing

“Split this e-commerce monolith into services” scored shape: capability-based cuts named (orders/inventory/billing/identity), litmus tests applied to ONE boundary out loud, shared-database prohibition stated, start-coarse advice given, team-topology mention. The interviewer watches whether you cut along DOMAIN lines or technical reflexes — that single distinction grades the whole answer.