title: Design a System

description: Produce a pragmatic high-level design for a system or feature.

content:
Design a system for: {{requirements}}

Deliver:
1. The core components and how they interact (a simple diagram in text is fine).
2. The data model and the main data flows.
3. The key trade-offs you made and what you optimized for.
4. How it handles scale, failure, and the top 2 risks.

State your assumptions about scale, consistency, and budget. Prefer the simplest design that meets the requirements; note where you'd add complexity later if needed.

requirements

description: What the system must do


title: Evaluate Architecture Options

description: Compare candidate approaches against your real constraints.

content:
I'm choosing between approaches for: {{problem}}

Candidates: {{options}}

For each, give: how it works in one line, its strengths, its weaknesses, and what it costs (complexity, latency, money, operational burden). Then recommend one for my context: {{constraints}}. Be explicit about the conditions under which your recommendation would change.

problem

description: The problem

options

description: The options you're weighing

constraints

description: Your constraints and priorities


title: Write an ADR

description: Capture an architecture decision in a clear, durable record.

content:
Write an Architecture Decision Record for this decision: {{decision}}

Use the standard structure:
- Title and status (proposed/accepted).
- Context: the forces and constraints that led here.
- Decision: what we're doing, stated plainly.
- Consequences: the good, the bad, and the newly-accepted risks.
- Alternatives considered and why they lost.

Keep it concise and honest — a future engineer should understand not just what we chose but why the obvious alternatives were rejected.

decision

description: The decision being recorded


title: Design a Data Model

description: Model entities, relationships, and constraints for a domain.

content:
Design a data model for: {{domain}}

Provide: the entities and their fields with types, the relationships and cardinalities, and the key constraints/invariants. Call out where you'd index, where you'd denormalize and why, and how the model handles the trickiest query: {{key_query}}. Note any modeling decision that would be expensive to reverse later.

domain

description: The domain to model

description: A demanding query it must serve


title: Plan an API Contract

description: Design a clean, evolvable API surface.

content:
Design the API for: {{service}}

Define the resources/operations, request and response shapes, error model, and pagination/filtering approach. Make it: consistent, hard to misuse, and evolvable without breaking clients. Specify versioning strategy and which fields are stable vs. experimental. Show the 2-3 most important calls with example payloads.

service

description: What the API serves


title: Identify Failure Modes

description: Stress-test a design by enumerating how it breaks.

content:
Here's my design/system: {{design}}

Do a failure-mode analysis. For each component and dependency, ask: what happens when it's slow, unavailable, returns garbage, or partially fails? Identify single points of failure, cascading-failure risks, and missing timeouts/retries/backpressure. Rank the failure modes by likelihood x impact and tell me the top three to address first.

design

description: The design to stress-test


title: Plan a Migration

description: Design a safe, incremental migration path.

content:
I need to migrate from {{current}} to {{target}}.

Design an incremental, reversible path: the sequence of steps, how to run old and new in parallel (and reconcile them), how to migrate data safely, and the rollback plan at each stage. Identify the riskiest step and how to de-risk it. Avoid any big-bang cutover unless you can justify it.

current

description: Current state

target

description: Target state


title: Decompose into Services or Modules

description: Find good boundaries for splitting a system.

content:
Help me decompose this system into modules/services: {{system}}

Find boundaries along the seams of change and ownership, not just nouns. For each proposed module: its single responsibility, what it owns, its interface, and its dependencies. Watch for chatty boundaries and shared databases. Tell me honestly whether this should stay a monolith with clean internal modules instead of being split.

system

description: The system to decompose


title: Estimate Capacity and Cost

description: Sanity-check scale and cost before building.

content:
For this system: {{system}}

Do a back-of-the-envelope estimate. From the expected load ({{load}}), work out requests per second, storage growth, bandwidth, and the rough infrastructure cost. Identify which resource becomes the bottleneck first and at what scale. Flag any number that's off by an order of magnitude from what I assumed. Keep the math visible so I can challenge it.

description: What the system does

load

description: Expected load / usage


title: Choose Sync vs Async

description: Decide whether work should be synchronous or queued.

content:
Should this be synchronous or asynchronous: {{operation}}

Decide based on: latency the caller can tolerate, whether the work can fail and be retried, ordering needs, and backpressure. If async, specify the queue, the retry and dead-letter policy, idempotency, and how the caller learns the result. If sync is fine, say so and avoid the complexity. Name the failure mode each choice introduces.

operation

description: The operation to place


title: Design for Idempotency

description: Make an operation safe to retry.

content:
This operation may be retried or duplicated: {{operation}}

Design it to be idempotent so duplicates do no harm. Choose the idempotency key, where to store the dedup record, and how long to keep it. Handle the race where two identical requests arrive at once. Show what happens on retry-after-partial-failure. Note any step that's inherently non-idempotent and how to fence it.

description: The operation to make idempotent


title: Define Service Boundaries

description: Specify what a service owns and how others talk to it.

content:
For this service: {{service}}

Define its boundary precisely: the data it owns (and that no one else writes), the operations it exposes, and the events it emits. Specify the contract: request and response shapes, error semantics, and consistency guarantees. Identify what it must NOT know about its callers. Flag any shared database or leaky coupling that would undermine the boundary.

service

description: The service to define


title: Choose a Consistency Model

description: Decide between strong and eventual consistency.

content:
For this data and these operations: {{scenario}}

Decide what consistency you actually need. Where would a stale or out-of-order read cause real harm (money, safety, correctness) versus merely look odd briefly? Recommend strong, eventual, or a mix per operation, and the mechanism (transactions, quorums, versioning, CRDTs). State the latency and availability cost of the choice. Flag where developers will assume stronger guarantees than the system provides.

scenario

description: The data and operations


title: Design an Event Schema

description: Define events that stay stable as the system evolves.

content:
I need to design events for: {{domain}}

Define each event: its name (past tense — something happened), the fields it carries, and what it must NOT carry. Decide between thin events (id only) and fat events (full payload) and the trade-off. Plan for evolution: how a consumer tolerates new fields, how you version a breaking change, and idempotency keys for duplicates. Flag any event that leaks producer internals consumers will couple to.

domain

description: The domain the events describe


title: Design a Rate Limiter

description: Protect a service with the right rate-limiting strategy.

content:
I need to rate-limit: {{target}}

Choose the algorithm (token bucket, leaky bucket, fixed or sliding window) and justify it for my traffic shape. Define the limit, the key (per user, IP, API key), where state lives, and what happens on exceed (reject with 429 + Retry-After, queue, or degrade). Handle the distributed case where many instances share a limit. Flag the failure mode where the limiter itself becomes the bottleneck or a single point of failure.

target

description: What you are rate-limiting


title: Design for Observability

description: Decide what to log, measure, and trace before building.

content:
For this system or feature: {{system}}

Design its observability up front. Define the key metrics (the few that reveal health and the user-facing SLIs), the logs worth keeping (and at what level), and where traces would untangle a cross-service request. Decide what a good dashboard shows at a glance and what alert would page someone — tied to symptoms users feel, not noisy internals. Flag what you would wish you had logged the first time this breaks.

system

description: The system or feature