// System design and architecture expert for creating scalable distributed systems. Covers system design interviews, architecture patterns, and real-world case studies like Netflix, Twitter, Uber. Use when designing systems, writing architecture docs, or preparing for system design interviews.
Code refactoring expert for improving code quality, readability, maintainability, and performance. Specializes in Java and Python refactoring patterns, eliminating code smells, and applying clean code principles. Use when refactoring code, improving existing implementations, or cleaning up technical debt.
Expert Java developer for implementing LeetCode problems, data structures, and algorithms. Helps write clean, efficient Java code following best practices for competitive programming and interview preparation. Use when writing or implementing Java solutions.
Comprehensive code reviewer for Java and Python implementations focusing on correctness, efficiency, code quality, and algorithmic optimization. Reviews LeetCode solutions, data structures, and algorithm implementations. Use when reviewing code, checking solutions, or providing feedback on implementations.
Technical documentation writer specializing in creating clear, well-structured markdown documents for algorithms, system design, interview preparation, and code documentation. Use when writing README files, algorithm explanations, system design docs, or technical guides.
| name | system-architecture |
| description | System design and architecture expert for creating scalable distributed systems. Covers system design interviews, architecture patterns, and real-world case studies like Netflix, Twitter, Uber. Use when designing systems, writing architecture docs, or preparing for system design interviews. |
| allowed-tools | Read, Glob, Grep, Write |
Use this Skill when:
Functional Requirements:
Non-Functional Requirements:
Constraints:
Example Questions:
- How many daily active users?
- What's the read:write ratio?
- What's the average data size?
- What's the peak load vs average load?
- Do we need real-time updates?
- Can we have data loss?
Calculate:
Traffic:
- DAU = 100M users
- Each user makes 10 requests/day
- QPS = 100M * 10 / 86400 ≈ 11,574 QPS
- Peak QPS = 2-3x average ≈ 30,000 QPS
Storage:
- 100M users * 1KB per user = 100GB
- With 3x replication = 300GB
- Growth: 300GB * 365 days = 109.5TB/year
Bandwidth:
- QPS * average request size
- 11,574 * 10KB = 115.74MB/s
Memory/Cache:
Core Components:
Draw Architecture:
[Clients] → [CDN]
↓
[Load Balancer]
↓
[Application Servers]
↙ ↓ ↘
[Cache] [DB] [Queue] → [Workers]
↓
[Object Storage]
SQL vs NoSQL Decision:
Use SQL when:
Use NoSQL when:
Sharding Strategy:
user_id % num_shardsSchema Design:
-- Example: URL Shortener
CREATE TABLE urls (
id BIGSERIAL PRIMARY KEY,
short_url VARCHAR(10) UNIQUE NOT NULL,
long_url TEXT NOT NULL,
user_id BIGINT,
created_at TIMESTAMP DEFAULT NOW(),
expires_at TIMESTAMP,
click_count INT DEFAULT 0,
INDEX (short_url),
INDEX (user_id)
);
Caching Strategy:
Eviction Policies:
Load Balancing:
Message Queue Patterns:
Horizontal Scaling:
Vertical Scaling:
Microservices:
Monolith:
[Single App] → [DB]
Microservices:
[User Service] → [User DB]
[Post Service] → [Post DB]
[Feed Service] → [Feed DB]
Benefits:
Drawbacks:
Replication:
Failover:
Rate Limiting:
Circuit Breaker:
States:
Closed → Normal operation
Open → Reject requests immediately
Half-Open → Test if service recovered
Content Delivery:
Data Consistency:
API Design:
RESTful:
GET /api/users/{id}
POST /api/users
PUT /api/users/{id}
DELETE /api/users/{id}
GraphQL:
query {
user(id: "123") {
name
posts {
title
}
}
}
Use this structure (based on system_design/00_template.md):
# {System Name}
## 1. Requirements
### Functional
- [List core features]
### Non-Functional
- Scale: [Users, QPS, Data]
- Performance: [Latency requirements]
- Availability: [Uptime target]
## 2. Capacity Estimation
- Traffic: [QPS calculations]
- Storage: [Data size, growth]
- Bandwidth: [Network requirements]
## 3. API Design
[endpoint] - [description]
## 4. High-Level Architecture
[Diagram]
## 5. Database Schema
[Tables and relationships]
## 6. Detailed Design
### Component 1
[Deep dive]
### Component 2
[Deep dive]
## 7. Scalability
[How to scale each component]
## 8. Trade-offs
[Decisions and alternatives]
Reference case studies in system_design/:
Common Patterns:
Time Management:
Communication:
What interviewers look for:
system_design/00_template.mdsystem_design/*.mddoc/system_design/