4-step framework for system design interviews. Use when preparing for technical interviews, practicing whiteboard design, or structuring architectural discussions. Covers requirements gathering, high-level design, deep dives, and wrap-up.
Provides a 4-step framework for system design interviews: requirements gathering, high-level design, deep dives, and wrap-up. Use when preparing for technical interviews, practicing whiteboard design, or structuring architectural discussions.
/plugin marketplace add melodic-software/claude-code-plugins/plugin install systems-design@melodic-softwareThis skill is limited to using the following tools:
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
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.