System Architecture Expert

When to use this Skill

Use this Skill when:

• Designing distributed systems

• Writing system design documentation

• Preparing for system design interviews

• Creating architecture diagrams

• Analyzing trade-offs between design choices

• Reviewing or improving existing system designs

System Design Framework

1. Requirements Gathering (5-10 minutes)

Functional Requirements:

• What are the core features?

• What actions can users perform?

• What are the inputs and outputs?

Non-Functional Requirements:

• Scale: How many users? How much data?

• Performance: Latency requirements? (p50, p95, p99)

• Availability: What uptime is needed? (99.9%, 99.99%)

• Consistency: Strong or eventual consistency?

Constraints:

• Budget limitations

• Technology stack constraints

• Team expertise

• Timeline

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?

2. Capacity Estimation (Back-of-the-envelope)

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:

• 80-20 rule: 20% of data gets 80% of traffic

• Cache = 20% of total data for hot data

3. High-Level Design

Core Components:

• Client Layer (Web, Mobile, Desktop)

• API Gateway / Load Balancer

• Application Servers (Business logic)

• Cache Layer (Redis, Memcached)

• Database (SQL, NoSQL, or both)

• Message Queue (Kafka, RabbitMQ)

• Object Storage (S3, GCS)

• CDN (CloudFront, Akamai)

Draw Architecture:

[Clients] → [CDN] ↓ [Load Balancer] ↓ [Application Servers] ↙ ↓ ↘ [Cache] [DB] [Queue] → [Workers] ↓ [Object Storage]

4. Database Design

SQL vs NoSQL Decision:

Use SQL when:

• ACID transactions required

• Complex queries with JOINs

• Structured data with relationships

• Examples: PostgreSQL, MySQL

Use NoSQL when:

• Massive scale (horizontal scaling)

• Flexible schema

• High write throughput

• Examples: Cassandra, DynamoDB, MongoDB

Sharding Strategy:

• Hash-based: user_id % num_shards

• Range-based: Users 1-100M on shard 1

• Geographic: US users on US shard

• Consistent hashing: For even distribution

Schema 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) );

5. Deep Dive Components

Caching Strategy:

• Cache-Aside: App reads from cache, loads from DB on miss

• Write-Through: Write to cache and DB together

• Write-Behind: Write to cache, async write to DB

Eviction Policies:

• LRU (Least Recently Used) - Most common

• LFU (Least Frequently Used)

• TTL (Time To Live)

Load Balancing:

• Round Robin: Simple, equal distribution

• Least Connections: Route to least busy server

• Consistent Hashing: Minimize redistribution

• Weighted: Based on server capacity

Message Queue Patterns:

• Pub/Sub: One-to-many (notifications)

• Work Queue: Task distribution (job processing)

• Fan-out: Broadcast to multiple queues

6. Scalability Patterns

Horizontal Scaling:

• Add more servers

• Use load balancers

• Stateless application servers

• Session stored in cache/DB

Vertical Scaling:

• Add more CPU/RAM to servers

• Limited by hardware

• Simpler but has limits

Microservices:

Monolith: [Single App] → [DB]

Microservices: [User Service] → [User DB] [Post Service] → [Post DB] [Feed Service] → [Feed DB]

Benefits:

• Independent scaling

• Technology flexibility

• Fault isolation

Drawbacks:

• Increased complexity

• Network latency

• Distributed transactions

7. Reliability & Availability

Replication:

• Master-Slave: One writer, multiple readers

• Master-Master: Multiple writers (conflict resolution needed)

• Multi-region: Geographic redundancy

Failover:

• Active-Passive: Standby server takes over

• Active-Active: Both servers handle traffic

Rate Limiting:

• Token bucket algorithm

• Leaky bucket algorithm

• Fixed window counter

• Sliding window log

Circuit Breaker:

States: Closed → Normal operation Open → Reject requests immediately Half-Open → Test if service recovered

8. Common System Design Patterns

Content Delivery:

• Use CDN for static assets

• Geo-distributed edge servers

• Cache at edge locations

Data Consistency:

• Strong Consistency: Read reflects latest write (ACID)

• Eventual Consistency: Reads eventually reflect write (BASE)

• CAP Theorem: Choose 2 of 3: Consistency, Availability, Partition Tolerance

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 } } }

9. System Design Template

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]

10. Real-World Examples

Reference case studies in system_design/ :

• Netflix: Video streaming, recommendation

• Twitter: Timeline, tweet storage, trending

• Uber: Real-time matching, location tracking

• Instagram: Image storage, feed generation

• WhatsApp: Message delivery, presence

Common Patterns:

• News Feed: Fan-out on write vs fan-out on read

• Rate Limiter: Token bucket with Redis

• URL Shortener: Base62 encoding, hash collision

• Chat System: WebSocket, message queue

• Notification: Push notification service, APNs/FCM

Interview Tips

Time Management:

• Requirements: 10%

• High-level design: 25%

• Deep dive: 50%

• Wrap up: 15%

Communication:

• Think out loud

• Ask clarifying questions

• Discuss trade-offs

• Acknowledge limitations

What interviewers look for:

• Problem-solving approach

• Technical depth

• Trade-off analysis

• Scale awareness

• Communication skills

Common Mistakes to Avoid

• Jumping to solution without requirements

• Over-engineering simple problems

• Under-estimating scale requirements

• Ignoring single points of failure

• Not considering monitoring/alerting

• Forgetting about data consistency

• Missing security considerations

Project Context

• Templates in system_design/00_template.md

• Case studies in system_design/*.md

• Reference materials in doc/system_design/

• Follow the established documentation pattern