From systems-design
Provides 4-step framework for system design interviews covering requirements gathering, high-level design, deep dives, and wrap-up. Use for technical interview prep, whiteboard practice, or architectural discussions.
How this skill is triggered — by the user, by Claude, or both
Slash command
/systems-design:design-interview-methodologyThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill provides a structured framework for approaching system design interviews and architectural discussions.
This skill provides a structured framework for approaching system design interviews and architectural discussions.
Keywords: system design interview, whiteboard design, architecture discussion, technical interview, design framework
Use this skill when:
System design interviews typically last 45-60 minutes. This framework ensures you cover all bases while demonstrating structured thinking.
| Step | Time | Purpose |
|---|---|---|
| 1. Requirements | 5-10 min | Clarify scope, constraints, scale |
| 2. High-Level Design | 10-15 min | Draw major components and data flow |
| 3. Deep Dive | 15-20 min | Detail 1-2 critical components |
| 4. Wrap-Up | 5-10 min | Trade-offs, bottlenecks, improvements |
Goal: Understand what to build and constraints before designing.
Ask about core functionality:
Clarify quality attributes:
| Category | Questions to Ask |
|---|---|
| Scale | How many users? DAU/MAU? Read/write ratio? |
| Performance | Latency requirements? Throughput targets? |
| Availability | Uptime requirements? (99.9% = 8.76 hours downtime/year) |
| Consistency | Strong or eventual consistency? |
| Durability | Data loss tolerance? Backup requirements? |
Quick calculations to inform design:
Example: Design a URL shortener
Users: 100M monthly active
Writes: 100M URLs/month = ~40 writes/second
Reads: 10:1 ratio = 400 reads/second
Storage: 100M * 500 bytes = 50GB/month = 600GB/year
Detailed estimation techniques: See estimation-techniques skill.
Before proceeding to design:
Goal: Draw the major components and show data flow.
Begin with the simplest architecture that could work:
Client --> API Gateway --> Service --> Database
Then add complexity as needed based on requirements.
| Component | When to Include |
|---|---|
| Load Balancer | Multiple servers, horizontal scaling |
| API Gateway | Authentication, rate limiting, routing |
| CDN | Static content, global users |
| Cache | Read-heavy, latency-sensitive |
| Message Queue | Async processing, decoupling |
| Database | Persistent storage (SQL vs NoSQL decision) |
| Search | Full-text search, complex queries |
| Object Storage | Large files, media content |
Walk through the system explaining each step:
"When a user creates a short URL:
1. Request hits the load balancer
2. API Gateway validates the request and checks rate limits
3. Service generates a unique short code
4. Short code and URL are stored in the database
5. Cache is updated for fast reads
6. Response returns the shortened URL"
Sketch key API endpoints:
POST /urls - Create short URL
GET /{shortCode} - Redirect to long URL
GET /urls/{id}/stats - Get click analytics
Show key tables/collections:
URLs table:
- id: primary key
- short_code: indexed, unique
- long_url: original URL
- user_id: foreign key
- created_at: timestamp
- expires_at: nullable timestamp
Goal: Demonstrate depth on 1-2 critical components.
Let the interviewer guide, or choose based on:
| Topic | What to Cover |
|---|---|
| Database scaling | Sharding strategy, replication, indexes |
| Caching | Cache strategy, invalidation, hit ratio |
| Data consistency | Conflict resolution, distributed transactions |
| Search | Indexing, ranking, query optimization |
| Messaging | Delivery guarantees, ordering, dead letters |
| Rate limiting | Algorithm choice, distributed implementation |
Option 1: Auto-increment
Pros: Simple, guaranteed unique
Cons: Predictable, single point of failure, hard to scale
Option 2: UUID
Pros: No coordination needed
Cons: Too long (36 chars), not URL-friendly
Option 3: Base62 encoding of counter
Pros: Short, URL-friendly
Cons: Requires coordination for distributed systems
Option 4: Pre-generated IDs
Pros: Fast, no runtime coordination
Cons: ID exhaustion, more complex
Recommendation: Pre-generated ID ranges + Base62 encoding
- Each server gets a range of IDs
- IDs are Base62 encoded for short URLs
- Handles distributed scale without coordination per request
Always explain trade-offs with specifics:
Goal: Summarize, identify issues, and propose improvements.
Where will the system break first as scale increases?
"The main bottleneck is the database. At 10x current scale:
- Write throughput becomes limiting
- Solution: Implement sharding by URL prefix
- Fallback: Read replicas for analytics queries"
Summarize key decisions and alternatives:
"We chose eventual consistency for the redirect cache:
- Benefit: Lower latency, simpler architecture
- Cost: Up to 5 seconds of stale data possible
- Alternative: Strong consistency with higher latency"
If you had more time, what would you add?
| Improvement | Benefit |
|---|---|
| Analytics pipeline | Usage insights, business value |
| Abuse detection | Malware/spam URL protection |
| Geographic distribution | Lower latency globally |
| A/B testing capability | Feature experimentation |
Mention edge cases you'd address:
Problem: Starting to design without understanding requirements. Fix: Spend 5-10 minutes on requirements first.
Problem: Adding every component you know. Fix: Start simple, add complexity only when justified by requirements.
Problem: Vague statements like "it's fast" or "it scales." Fix: Use numbers: "handles 10K requests/second with p99 latency of 50ms."
Problem: Presenting only benefits of your design. Fix: Actively discuss what you're sacrificing for each decision.
Problem: Drawing without explaining. Fix: Narrate your thought process constantly.
| Situation | Response |
|---|---|
| Running short on time | Skip to wrap-up, summarize trade-offs |
| Interviewer redirects | Follow their lead, they're guiding you |
| Stuck on a component | Acknowledge, move on, come back if time |
| Asked unknown technology | Explain your reasoning, ask about constraints |
design-problem-catalog skill - Phase 4)estimation-techniques skill)quality-attributes-taxonomy skill)estimation-techniques - Back-of-envelope calculations for scalequality-attributes-taxonomy - NFRs and the "-ilities"cap-theorem - Consistency/availability trade-offs (Phase 2)design-problem-catalog - Common interview problems (Phase 4)/sd:design <problem> - Interactive design session (Phase 4)/sd:estimate <scenario> - Capacity calculations/sd:explain <concept> - Explain any conceptsystem-design-interviewer - Mock interview practice (Phase 4)capacity-planner - Back-of-envelope calculationsarchitecture-critic - Challenge your designs (Phase 4)Date: 2025-12-26 Model: claude-opus-4-5-20251101
npx claudepluginhub melodic-software/claude-code-plugins --plugin systems-designStructures a complete system design answer for interview questions or real architecture sessions. Covers requirements, capacity estimates, high-level design, component deep-dives, trade-offs, and follow-up considerations.
Guides distributed systems design with 4-step framework. CHECKER audits designs for gaps and anti-patterns; APPLIER interactively builds systems step-by-step. Covers 15 designs like rate limiters, KV stores, news feeds.
Prepare for architecture interview questions and scenarios. Practice system design, tradeoff discussions, communication. Use for career development and interview readiness.