Managing Critical and Optional Dependencies

For each service, list its dependencies (databases, caches, internal services, third-party APIs, DNS, auth, secrets, feature-flag service) and classify them: critical (request can't succeed without it) or optional (degrade). For each: timeout, retry policy, breaker, bulkhead, fallback, owner and SLO. Minimize critical dependencies on the request path; move non-essential calls async; cache configuration (flags, secrets) locally so the control plane being down doesn't take you down.

Dependency register — checkout-service
| Dependency      | Criticality | Timeout | Retries      | Breaker | Fallback                  |
| payments-api    | critical    | 2 s     | 1 (keyed)    | yes     | 202 + async completion    |
| inventory       | critical    | 250 ms  | 1            | yes     | reserve later + recheck   |
| recommendations | optional    | 200 ms  | 0            | yes     | popular items (cached)    |
| feature flags   | optional    | local   | —            | —       | last known config         |
| email (outbox)  | async       | —       | worker-level | —       | retry queue               |

Common pitfalls

• Implicit dependencies discovered during outages.
• Control-plane services (flags, config, auth metadata) on the hot path without caching.
• Third-party SDKs without timeouts.

Key points

• Inventory and classify dependencies
• Explicit policy per dependency
• Cache control-plane data locally

Further reading: AWS Builders' Library: Static stability