Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →nwave-ai/nw-sd-patterns
Core distributed systems patterns - load balancing, caching, sharding, consistent hashing, message queues, rate limiting, CDN, Bloom filters, ID generation, replication, conflict resolution, CAP theorem
Passed 18 of 22 test cases with the skill, and 16 of 22 without it.
and 1 more in the full report
2 fixed16 passed either way4 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
Our engineering team is building a location-based mobile application that requires efficient proximity searches and low-latency status updates to clients. We need an architectural breakdown comparing spatial indexing choices and server-to-client messaging protocols. Please format your response with pros-and-cons tables for each technology category and conclude with a recommended component integration pattern.
| Checked | Without skill | With skill |
|---|---|---|
| Compares Geohash against Quadtree for spatial indexing options | Missed | Passed |
| Includes Long Polling alongside WebSockets and Server-Sent Events for real-time communication options | Missed | Passed |
| Notes that Quadtree recursively subdivides space into 4 quadrants adaptively based on density | Missed | Passed |
The instructions your model reads when the skill loads.
Problem: single server can't handle all traffic.
Approaches: Round Robin (simple, ignores load) | Weighted Round Robin (accounts for capacity) | Least Connections (fewest active) | IP Hash (session affinity) | Layer 4/transport (IP/port, fast) | Layer 7/application (HTTP-aware, smarter)
Placement: client-to-web | web-to-app | app-to-database
Trade-offs: LB itself is SPOF -- use active-passive pair | session affinity complicates horizontal scaling -- prefer stateless servers | health checks critical
Problem: repeated DB reads are slow.
Strategies: Cache-aside/lazy loading (app checks cache, fills on miss -- most common) | Write-through (write cache+DB simultaneously) | Write-behind (cache only, async to DB) | Read-through (cache fronts DB transparently)
Cache-aside pattern: Read: cache.get(key) -> hit? return : db.read -> cache.set -> return | Write: db.write -> cache.delete(key)
Eviction: LRU (most common) | LFU (skewed access) | TTL (time-based)
Problems: thundering herd (many misses simultaneously -- use locking/coalescing) | cache penetration (non-existent keys -- Bloom filter or cache null) | cache avalanche (mass expiration -- jittered TTLs) | size cache based on working set, not total data
Master-Slave: all writes to master, reads to replicas | replication lag = eventual consistency | master fails: promote replica
Multi-Master: writes to any node, conflict resolution required | better write availability, much more complex | suitable for multi-region
Trade-offs: sync replication = consistency but higher write latency | async = lower latency but data loss risk on failure
Problem: single DB can't handle write volume or data size.
Strategies: Hash-based (hash(key) % N -- even but resharding painful) | Range-based (ranges, can have hotspots) | Directory-based (lookup table, flexible but SPOF)
Partition key: must distribute data AND queries evenly | must be in most queries | common: user_id, tenant_id, region
test cases passed, vs 16 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.