Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →nwave-ai/nw-sd-patterns-advanced
Advanced distributed patterns - event sourcing, CQRS, saga, stream processing, append-only log, exactly-once delivery, sequencer, double-entry ledger, erasure coding, order book, watermarks
Passed 21 of 22 test cases with the skill, and 20 of 22 without it.
1 fixed20 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
A test case the skill fixed. Same model, same prompt, with and without the skill.
Our financial exchange matching engine requires sub-microsecond processing latencies. What memory management and concurrency strategies should be used on the core order processing thread?
| Checked | Without skill | With skill |
|---|---|---|
| Recommends single-threaded execution per symbol to eliminate lock overhead | Passed | Passed |
| Recommends pre-allocated memory pools to prevent garbage collection allocations | Missed | Passed |
The instructions your model reads when the skill loads.
Problem: need audit trail, state reconstruction, temporal queries.
Core idea: store every state change as immutable event, not current state.
Events: [WalletCreated: balance=0] [Deposited: +100] [Transferred: -30] [Deposited: +50]
Current state: 0 + 100 - 30 + 50 = 120
Benefits: complete audit trail | temporal queries ("balance on Jan 15?") | rebuild state from scratch | debug by replay | event-driven architecture
Challenges: computing state requires replaying all events -- use snapshots | schema evolution (events immutable) | store grows indefinitely -- compaction/archiving | eventual consistency for read models
Snapshots: periodically save computed state | current state = latest snapshot + events after it | trade-off: recovery speed vs storage
Used in: payment systems, banking, trading platforms, audit-critical systems
Problem: read and write models have different optimization needs.
Architecture: Commands -> Write Model (normalized, consistency) -> events/CDC -> Read Model (denormalized, query-optimized) <- Queries
When: very different read/write patterns | read model needs heavy denormalization | different scaling for reads vs writes | paired with Event Sourcing
Trade-offs: eventual consistency between models | increased complexity (two models) | sync lag
Problem: distributed transactions across services without 2PC.
Core idea: sequence of local transactions, each with compensating action.
Each service listens for events and acts | no central coordinator | simpler but harder to track/debug
test cases passed, vs 20 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.