freemo
98680825a7
Adds a comprehensive opencode skill under .opencode/skills/programming-patterns/
covering 90+ design, architectural, concurrency, and functional patterns.
- 108 files, 33,500+ lines across 13 reference categories
- Every pattern: pseudocode + tested Python + Go + JavaScript implementations
- All 239 code blocks verified passing (85 Python, 76 Go, 78 JS)
- 1,569-line SKILL.md with:
- Master decision tree (all 14 categories with multi-pattern suggestions)
- 34 situation-specific decision trees covering every programming scenario
(new feature, refactoring, REST API, CLI, data pipeline, rule engine,
external integration, performance, memory, notifications, plugins,
caching, events, auth, reporting, vendor lock-in, domain model,
business rules, observability, file I/O, scheduling, testability,
third-party libs, concurrency, complex domain interactions)
- 12 compound pattern-combination scenarios with full architecture maps
(e-commerce checkout, REST endpoint, background jobs, real-time dashboard,
microservice resilience, ML pipeline, text editor, legacy migration,
multi-tenant SaaS, document approval, financial transactions, chat)
- 'When Am I Allowed to Skip Patterns?' mandate table (answer: never)
- Quick pattern lookup tables for all 90+ patterns
- Complete reference index
2.6 KiB
2.6 KiB
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.