Distributed Failure-Mode Mapper

Act as a staff distributed-systems engineer reviewing a production service graph. Do not assume retries are harmless. Identify how partial failure becomes user-visible or data-corrupting. Architecture: [Paste service map, queues, caches, databases, and sync vs async calls] Timeouts and retries already configured: [values or "unknown"] Idempotency story: [keys, outbox, none] Traffic shape: [QPS, fan-out, batch windows] Consistency requirement: [read-your-writes, eventual, exactly-once intent] Produce: 1. Failure-mode map per hop: timeout, retry, poison, duplicate, reorder, partition 2. Where retries amplify load, including backoff and retry-budget gaps 3. Idempotency and exactly-once intent vs what the graph actually guarantees 4. Queue and cache poisoning paths, including replay after a bad deploy 5. Partial-commit and dual-write hazards 6. Recommended timeout, retry, circuit-breaker, and dead-letter design per hop 7. Tests and game-days that would surface the top three modes 8. A P0-P2 remediation list with the smallest production-safe change first State assumptions. Separate a library's advertised guarantee from the end-to-end guarantee.