matilha-sysdesign-pack

Use when the user mentions system design, scalability, distributed systems, latency, throughput, availability, CAP theorem, database design, caching, rate limiting, CDN, microservices, SLA, NFR, capacity planning, bottleneck, message queue, or any topic related to large-scale system architecture and infrastructure design. Fires independently of compose to ensure matilha-sysdesign-pack skills activate whenever system design domain appears.

Use when designing autocomplete / search suggestions — weighted trie for top-k prefix matches, query sampling, fuzzy matching, and pre-serve moderation.

Use when serving images, video, or downloads globally — places a CDN in front of an object store, names invalidation strategy, and handles private-content auth.

Use when handling message failures in a queue or stream — installs a DLQ with retry policy, backoff, alerting on growth, and a reprocess-after-fix flow.

Use when a design writes to two stores on one action (DB + Kafka, DB + cache, DB + search) or when deciding whether event sourcing is worth its complexity.

Use when deciding between Kafka and a simpler queue — picks Kafka for decoupling, ordered delivery, and replay, or rejects it for low-volume point-to-point work.

Use when designing write endpoints that may be retried — install idempotency keys, dedup stores, and at-most-once semantics to prevent duplicate effects.

Use when approaching a new system design — a 50-minute flow (requirements → API → data model/arch → deep dive → monitoring) that doubles as a spec-authoring template.

Use when deciding what to monitor and alert on — applies the 4 golden signals (Latency, Traffic, Errors, Saturation) and splits page-worthy from dashboard-only.

Use when designing a social feed (Twitter, Facebook, Instagram-style) and weighing fan-out on write vs fan-out on read, especially with celebrity-scale accounts.

Use when choosing a rate-limiting algorithm — picks token bucket, leaky bucket, fixed window, or sliding window and places it stateful vs stateless.

Use when designing a real-time top-K dashboard (top trending, top errors, top products) — count-min sketch for bounded memory, Lambda vs Kappa architecture, mandatory checkpointing.

Use when a team is about to make an architectural choice (X vs Y, SQL vs NoSQL, sync vs async) — forces explicit tradeoff articulation tied to NFR priorities.

Use when asked "qual LB usar?" / "HAProxy vs ALB?" — chooses between hardware, LBaaS, and software (HAProxy/NGINX), picks L4 vs L7, and handles sticky sessions + TLS termination.

Use when asked "strong ou eventual consistency?" / "qual banco?" — forces CAP choice (CP vs AP), maps it to HBase/Mongo/Redis vs Cassandra/Dynamo, and selects coordination technique.

Use when asked "como reduzir latency?" / "P99 alto" — sets target per percentile, distinguishes latency vs throughput vs bandwidth, and applies GeoDNS, CDN, caching, RPC-over-REST.

Use when asked "como tolerar falhas?" / "o que fazer quando X cai?" — selects between circuit breaker, exponential backoff+jitter, bulkhead, DLQ, checkpointing, fallback, and replication patterns.

Use when discussing SLA targets, uptime, or "quanto de downtime aceitável?" — translates availability tiers into minutes/hours, forces MTTR/MTBF awareness, and exposes CAP tradeoff cost.

Use when asked "como escalo Y" or "vertical ou horizontal?" — decides between scaling up the host vs adding more hosts, and surfaces the stateless/shared-write trap.

Use when about to draft system architecture or hear "antes de desenhar X" / "vamos modelar o sistema" — forces clarification of the 10 non-functional requirements before a single box gets drawn.