Service Dependency Mapper#

Map your service dependencies before an outage teaches you what they are. Auto-discover dependencies from code imports, config files, network traffic, and runtime traces — then generate dependency graphs, identify critical paths, and assess blast radius.

Use when: "map our services", "what depends on what", "service dependency graph", "blast radius analysis", "single point of failure", "what breaks if X goes down", "architecture visualization", or during incident planning.

Commands#

1. discover — Auto-Detect Service Dependencies#

Step 1: Static Analysis — Code and Config

bash

# Find service URLs in code
rg "https?://[a-z][-a-z0-9]*(\.[a-z][-a-z0-9]*)*[:/]" \
  --type-not binary -g '!node_modules' -g '!vendor' -g '!*.test.*' 2>/dev/null | \
  grep -v "example\.com\|localhost\|127\.0\.\|schema\.org" | head -30

# Find service names in Docker Compose
rg "depends_on|links:|container_name:" docker-compose*.yml 2>/dev/null

# Find service references in Kubernetes
rg "serviceName:|host:|backend:" k8s/ manifests/ helm/ 2>/dev/null

# Find database/cache connections
rg "DATABASE_URL|REDIS_URL|MONGO_URI|POSTGRES_|MYSQL_|AMQP_URL|KAFKA_BROKER" \
  --type-not binary -g '!node_modules' -g '!vendor' 2>/dev/null

# Find message queue producers/consumers
rg "publish\(|subscribe\(|produce\(|consume\(|\.queue\(|channel\." \
  --type-not binary -g '!node_modules' -g '!vendor' 2>/dev/null | head -20

# Find gRPC/REST client instantiations
rg "GrpcClient|HttpClient|axios\.create|fetch\(.*service|\.NewClient" \
  --type-not binary -g '!node_modules' -g '!vendor' 2>/dev/null

Step 2: Runtime Analysis (if available)

bash

# Kubernetes services
kubectl get services -A -o json | python3 -c "
import json, sys
svcs = json.load(sys.stdin)['items']
for svc in svcs:
    ns = svc['metadata']['namespace']
    name = svc['metadata']['name']
    stype = svc['spec']['type']
    ports = [str(p['port']) for p in svc['spec'].get('ports', [])]
    print(f'{ns}/{name} ({stype}) ports:{','.join(ports)}')
"

# Service mesh (Istio/Linkerd) — actual traffic dependencies
kubectl get destinationrules -A 2>/dev/null
istioctl proxy-config cluster <pod-name> 2>/dev/null | grep -v "BlackHole\|PassthroughCluster"

Step 3: Build Dependency Graph

python

dependencies = {
    'api-gateway': {
        'depends_on': ['auth-service', 'user-service', 'order-service'],
        'type': 'sync',  # sync HTTP calls
        'criticality': 'critical',
    },
    'order-service': {
        'depends_on': ['postgres', 'payment-service', 'kafka'],
        'type': 'mixed',
        'criticality': 'critical',
    },
    'notification-service': {
        'depends_on': ['kafka', 'smtp-relay', 'redis'],
        'type': 'async',
        'criticality': 'low',
    },
}

Step 4: Generate Dependency Map

markdown

# Service Dependency Map

## Graph (text representation)

[External Users] │ ▼ [api-gateway] ─sync──► [auth-service] ─sync──► [postgres-auth] │ │ │ ├─sync──► [user-service] ─sync──► [postgres-users] │ │ └─async─► [redis-cache] │ │ │ └─sync──► [order-service] ─sync──► [postgres-orders] │ │ └─sync──► [payment-service] ─► [Stripe API] │ │ │ └─async──► [kafka] │ │ │ ├──► [notification-service] ─► [SMTP] │ └──► [analytics-service] ─► [ClickHouse]

text

## Critical Path
api-gateway → order-service → postgres-orders
(Failure here = orders cannot be placed)

## Single Points of Failure
1. 🔴 **postgres-orders** — no replica, single instance
2. 🔴 **api-gateway** — single entry point, no fallback
3. 🟡 **kafka** — 3 brokers but no multi-AZ
4. 🟡 **Stripe API** — external dependency, no fallback payment provider

## Blast Radius Analysis
| If this fails... | These break... | Users affected |
|-------------------|---------------|----------------|
| postgres-orders | order-service, api-gateway (partial) | 100% orders |
| auth-service | All authenticated endpoints | 100% users |
| kafka | notifications, analytics | 0% (graceful degradation) |
| redis-cache | user-service (slow, not down) | 0% (cache miss only) |
| Stripe API | payment-service, orders | 100% new orders |

2. blast-radius — Analyze Impact of Service Failure#

For a given service, trace all dependents (recursively):

• Direct dependents (call this service)
• Transitive dependents (depend on direct dependents)
• User-facing impact (which user flows break?)
• Graceful degradation (can dependents function without this service?)

3. visualize — Generate Diagram#

Output dependency graph in:

• Mermaid (for GitHub/GitLab markdown)
• DOT (for Graphviz)
• PlantUML
• D2

4. health — Assess Architecture Health#

Score the architecture based on:

• Depth of dependency chain (deep chains = fragile)
• Fan-out per service (wide fan-out = complex failure modes)
• Circular dependencies (exist? how many?)
• Single points of failure count
• Ratio of sync vs async dependencies
• External dependency count and fallback coverage