freemo
d9e5668cec
Fixes and improvements from exhaustive audit: Consistency fixes in SKILL.md: - 'Pipe & Filter' → 'Pipe and Filter' (one stray '&' found and corrected) - 'Singleton for factory instance' → clarified to 'register factory as singleton-scoped via DI container' (less misleading wording) - Documentation Format section updated with note that SKILL.md itself is the authoritative source for related-pattern combinations Coverage fix — Related Patterns sections: - Added '## Related Patterns' to ALL 94 pattern files (was 0/94) - Each section lists 3–6 related patterns with relationship descriptions - Covers: why they're related, when to prefer one vs the other, and which are often confused SOLID principles → Creational → Structural → Behavioral → Architectural → Concurrency → Functional → Resilience → Data Access → Messaging → Testing → Error Handling → Microservice — all 13 categories covered Code verification: - Python: 0 failures (all 85 testable blocks pass) - Go: 0 failures (all 76 testable blocks pass) - JavaScript: 0 failures (all 78 testable blocks pass) - All 239 code blocks verified correct after edits Final skill state: - 108 files, 36,524 lines across 13 reference categories - 94/94 pattern files have Related Patterns sections - 2,815-line SKILL.md with 67 decision trees, 23 scenarios, 0 broken references, 0 naming inconsistencies
Resilience Patterns
Resilience patterns help systems survive and recover from failures — partial outages, network hiccups, overloaded dependencies, and cascading errors. They operate on the principle that failures are inevitable, and software must be designed to handle them gracefully.
Pattern Comparison
| Pattern | Purpose | Scope | Complexity |
|---|---|---|---|
| Circuit Breaker | Stop calling a failing service; let it recover | Per-dependency | Medium |
| Retry | Reattempt transient failures with backoff | Per-call | Low |
| Bulkhead | Isolate failures so they don't cascade | Per-resource | Medium |
| Saga | Coordinate distributed transactions with compensation | Cross-service | High |
| Rate Limiter | Throttle request throughput | Per-client / global | Low–Medium |
| Timeout | Bound how long a call can block | Per-call | Low |
| Fallback | Provide degraded functionality on failure | Per-call | Low |
Decision Guide
Is the remote service flaky?
├─ Yes → Circuit Breaker + Retry
│ Add Timeout to bound each attempt
│ Add Fallback for graceful degradation
└─ No → Could it become overloaded?
├─ Yes → Rate Limiter + Bulkhead
└─ No → Is there a multi-step workflow?
├─ Yes → Saga
└─ No → Timeout + Fallback as baseline
Combining Patterns
Resilience patterns compose well. A typical call stack:
Rate Limiter
└─ Timeout
└─ Circuit Breaker
└─ Retry (with backoff)
└─ Bulkhead (isolated pool)
└─ Actual call
└─ Fallback (on any failure)
Key Principles
- Fail fast — Don't waste resources on calls that will likely fail.
- Fail gracefully — Return something useful even when degraded.
- Isolate failures — One bad dependency must not bring down everything.
- Recover automatically — Systems should self-heal without manual intervention.
- Observe everything — Metrics and logs are essential for tuning thresholds.