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
Microservice Patterns
Overview
Microservice patterns address the challenges of building, deploying, and operating distributed systems composed of independently deployable services. They solve problems around routing, discovery, migration, cross-cutting concerns, and client-specific API needs.
Pattern Comparison
| Pattern | Purpose | Scope | Key Benefit |
|---|---|---|---|
| API Gateway | Single entry point routing to backend services | Infrastructure / Edge | Centralised routing, auth, rate limiting |
| Service Discovery | Dynamic registration and lookup of services | Infrastructure | No hardcoded service addresses |
| Strangler Fig | Incremental migration from monolith to microservices | Migration | Zero-downtime, gradual replacement |
| Sidecar | Helper process for cross-cutting concerns | Deployment | Separation of business and infra logic |
| Backend for Frontend | Client-specific API aggregation | API Layer | Optimised APIs per client type |
When to Use Which
- Need a single entry point for external clients? Use API Gateway to route, authenticate, and rate-limit at the edge.
- Services come and go dynamically (scaling, deployments)? Use Service Discovery so callers find services without hardcoded URLs.
- Migrating a monolith gradually? Use Strangler Fig to route traffic between old and new systems incrementally.
- Multiple services need the same infra concerns (logging, TLS, metrics)? Use Sidecar to handle them uniformly without modifying each service.
- Mobile and web clients need different API shapes? Use Backend for Frontend to create optimised aggregation layers per client.
Relationships Between Patterns
- API Gateway often incorporates Service Discovery to find backend services dynamically.
- Strangler Fig is commonly implemented inside an API Gateway (routing rules shift traffic).
- Sidecar runs alongside each service instance; the API Gateway is a cluster-wide singleton.
- Backend for Frontend sits behind the API Gateway or is itself a specialised gateway per client.
- Service Discovery is a foundational pattern used by nearly all others.
Design Guidelines
- Start simple — not every system needs all five patterns on day one.
- Prefer convention over configuration — use naming conventions for discovery and routing.
- Design for failure — every network call can fail; add timeouts, retries, and circuit breakers.
- Observe everything — distributed tracing, metrics, and structured logging are essential.
- Own your data — each microservice owns its data store; no shared databases.