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.3 KiB
2.3 KiB
Messaging Patterns
Messaging patterns define how components communicate asynchronously — decoupling producers from consumers in time, space, and implementation. They are fundamental to event-driven architectures, microservices, and any system that needs to handle work without blocking the caller.
Pattern Comparison
| Pattern | Delivery | Coupling | Consumers | Use Case |
|---|---|---|---|---|
| Publish-Subscribe | Fan-out to all subscribers | Low (topic-based) | Many | Notifications, event broadcasting |
| Message Queue | Point-to-point, one consumer | Low | One (competing consumers) | Work distribution, task processing |
| Event Bus | In-process fan-out | Low (in-process) | Many (in-process) | Modular monolith, plugin systems |
| Request-Reply | Correlated request/response | Medium | One | RPC over messaging, async queries |
| Dead Letter Queue | Failed message routing | Low | One (error handler) | Error handling, poison messages |
Decision Guide
Is communication within a single process?
├─ Yes → Event Bus
└─ No → Is it broadcast (many consumers)?
├─ Yes → Publish-Subscribe
└─ No → Is it fire-and-forget work?
├─ Yes → Message Queue
│ └─ Handle failures → Dead Letter Queue
└─ No → Need a response?
└─ Yes → Request-Reply
Combining Patterns
Messaging patterns layer naturally:
Producer
└─ Publishes to Topic (Pub/Sub)
├─ Subscriber A → Message Queue (work distribution)
│ └─ Failures → Dead Letter Queue
├─ Subscriber B → Request-Reply (enrichment)
└─ Subscriber C → Event Bus (in-process dispatch)
Key Principles
- Decouple producers and consumers — Neither should know about the other's implementation.
- Make messages self-describing — Include enough context to process without callbacks.
- Handle failures explicitly — Dead letter queues prevent poison messages from blocking processing.
- Idempotency — Consumers must handle duplicate messages gracefully.
- Ordering matters — Know whether your messaging system guarantees order, and design accordingly.