fault-tolerant-design

Reviews software designs for isolation, redundancy, static stability, and progressive delivery under failure.

Updated May 27, 2026
One-click install
npx skills add https://github.com/ybaspinar/agent-work-skills --skill fault-tolerant-design-ybaspinar
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fault-tolerant-design
Source: https://github.com/ybaspinar/agent-work-skills/tree/main/skills/fault-tolerant-design
Command: npx skills add https://github.com/ybaspinar/agent-work-skills --skill fault-tolerant-design-ybaspinar

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Reliability-sensitive systems often break when dependencies, processes, deploys, or infrastructure fail, and design reviews frequently miss cascade risks, shared-fate components, and unsafe rollouts. This Skill provides a structured review framework that keeps critical paths working through dependency failures and limits blast radius when changes go wrong. ## Core Features & Use Cases - Structured Reliability Review: Evaluates designs across five principles—isolation, redundancy, static stability, recovery practice, and progressive delivery—with a ready-to-use output template covering critical path, failure modes, and recommendations. - Concrete Review Heuristics: Provides actionable guidance such as keeping non-essential dependencies out of critical paths, preferring last known good state over live reads, requiring bounded retries with dead-lettering, and rehearsing rollback before relying on feature flags. - Use Case: When reviewing a worker that calls an external API before writing to the database, the Skill produces a review stating that ingestion must not depend on optional enrichment, that last known good enrichment should be preserved with freshness timestamps, and that retries must be bounded, idempotent, and dead-lettered. ## Quick Start Review this background job design for fault tolerance, covering the critical path, dependency isolation, static stability, recovery practice, and rollout plan.

Frequently Asked Questions about fault-tolerant-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a system design for fault tolerance?

Review the design across five principles: isolation of the critical path, redundancy with separate failure domains, static stability using last known good state, exercised recovery paths, and progressive delivery. The Skill provides a structured output template covering each area plus failure modes and recommendations.

How to handle external API failures in background workers?

Keep the external API call out of the ingestion critical path when the work is optional. Preserve last known good results with freshness timestamps, and use bounded retries with backoff, idempotent writes, and a dead-letter queue so replay is safe.

Should every request fetch config from a control service?

No, fetching config on every request makes serving traffic depend on the control plane. Move config refresh out of the request path and serve from a last known good snapshot with version, age, and safety limits, so a control-service outage blocks config changes rather than existing traffic.

When should I not add redundancy to a system?

Do not add redundancy when removing the dependency is simpler, or when failure impact does not justify the complexity. Copies are not truly redundant if they share the same database, queue, region, or deploy step, and retries alone do not make a system fault tolerant.

Why are feature flags not enough for safe rollouts?

Feature flags only count as safety when rollback is fast, observable, and state-compatible. If a change has altered data or schema, disabling the flag may not restore safe behavior, so rollback or forward-fix paths must be rehearsed before relying on flags.