Lesson 2: Resolution Strategies

Strategy 1: Manual Resolution

Human decides which element to use:

# Mark one as canonical
sruja resolve --canonical "user-service::API" \
  --alias "order-service::API" \
  --to "user-service::API"

This updates the system index:

{
  "resolved": {
    "order-service::API": "user-service::API"
  }
}

Strategy 2: Aliasing

Keep both but disambiguate:

# Add repo prefix to one
sruja resolve --alias "order-service::API" \
  --rename "order-service-order-api"

Result in DSL:

<!-- partial -->
// Both preserved, now distinct
user-service::API
order-service::order-api

Strategy 3: Merging

Combine two elements:

# Merge into single canonical
sruja resolve --merge "user-service::API" \
  --with "order-service::API" \
  --canonical "unified::API" \
  --ownership "shared-team"

This requires:

• Merging DSL definitions
• Updating all references
• Defining new ownership

Strategy 4: Deprecation

Mark one as deprecated:

# Deprecate duplicate
sruja resolve --deprecate "legacy-auth::AuthAPI" \
  --reason "Replaced by auth-service::AuthAPI" \
  --migrate-to "auth-service::AuthAPI"

Deprecated elements:

• Still visible in history
• Flagged in reports
• Block new usage

Resolution Workflow

1. Detect conflict
   └─→ sruja compose -i ./bundles -o system.index.json

2. Analyze options
   └─→ Same service in multiple repos? → MERGE or RENAME
   └─→ Different services with same name? → USE ALIASES
   └─→ One is legacy? → DEPRECATE and remove

3. Update DSL in affected repos
   └─→ Rename conflicting components
   └─→ Update references

4. Re-compose and verify
   └─→ sruja compose -i ./bundles -o system.index.json

5. Validate no new conflicts
   └─→ sruja lint repo.sruja

Handling Blocked Composition

If composition detects conflicts:

# View the conflicts in the system index
cat system.index.json | jq '.conflicts'

# Resolve by updating DSL to use unique names
# Then republish and recompose
sruja publish -r . -o updated-bundle.json

Hands-On: Resolve a Conflict

1. Compose and detect conflicts:

   sruja compose -i ./bundles -o system.index.json
   cat system.index.json | jq '.conflicts'
   

2. Identify the conflicting components:

   # Look for duplicate kind+label
   cat system.index.json | jq '.nodes[] | select(.label == "API")'
   

3. Rename to resolve (example): In order-service/repo.sruja, rename API to OrderAPI:

   OrderAPI = container "Order API" {
     description "API for order management"
   }
   

4. Republish and recompose:

   sruja publish -r ./order-service -o ./bundles/order-service.bundle.json
   sruja compose -i ./bundles -o system.index.json
   

Learning Outcomes

• ✅ Understand different conflict resolution strategies
• ✅ Detect conflicts during bundle composition
• ✅ Apply renaming or aliasing to resolve conflicts
• ✅ Validate resolution by recomposing bundles

Quiz: Test Your Understanding

Q1: What typically causes conflicts in federated architecture?

A) Network timeouts B) Two repos modeling the same logical element or using the same name C) Git merge conflicts D) Database lock contention

Q2: What is the first step when you detect a conflict in composition?

A) Delete one of the bundles B) Analyze whether the elements are actually the same or just have similar names C) Contact the cloud provider D) Disable CI/CD

Q3: After resolving a conflict, what should you do?

A) Nothing - conflicts auto-resolve B) Republish affected bundles and recompose C) Delete the system index D) Restart all services

Next Steps

Lesson 3 covers preventing future conflicts.