ihiteshgupta System Design & Solution Architecture Expert
Purpose
Provide expert guidance on system architecture, design patterns, scalability, distributed systems, and comprehensive solution design for complex software systems.
When to Use This Skill
- Designing new systems from scratch
- Architecting microservices
- Planning for scale and performance
- Distributed systems design
- Technology stack selection
- System migration planning
- Capacity planning
- Architecture documentation
Core Design Principles
1. SOLID Principles
- Single Responsibility Principle
- Open/Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
2. Scalability Patterns
- Horizontal Scaling (Scale Out)
- Vertical Scaling (Scale Up)
- Load Balancing
- Caching Strategies
- Database Sharding
- Read Replicas
- CDN for Static Assets
3. Reliability Patterns
- Circuit Breaker
- Retry with Exponential Backoff
- Bulkhead Pattern
- Health Checks
- Graceful Degradation
- Failover Mechanisms
4. Design Patterns
Creational Patterns
- Singleton - Single instance
- Factory - Object creation interface
- Builder - Complex object construction
- Prototype - Clone existing objects
Structural Patterns
- Adapter - Interface compatibility
- Decorator - Add behavior dynamically
- Facade - Simplified interface
- Proxy - Placeholder for another object
Behavioral Patterns
- Observer - Event notification
- Strategy - Interchangeable algorithms
- Command - Encapsulate requests
- State - Behavior based on state
System Design Process
1. Requirements Gathering
Functional Requirements:
- What features does the system need?
- What are the core user flows?
- What operations are most critical?
Non-Functional Requirements:
- Expected traffic (QPS, DAU, MAU)
- Data volume and growth
- Latency requirements (p50, p95, p99)
- Availability requirements (99.9%, 99.99%)
- Consistency requirements
- Security requirements
2. Capacity Planning
Calculate:
- Storage: Users × Data per user × Growth rate
- Bandwidth: Requests/sec × Average request size
- Memory: Cache size + Active sessions
- Compute: CPU/Memory per request × QPS
3. High-Level Design
Components:
1. Client Layer (Web, Mobile, Desktop)
2. Edge Layer (CDN, Load Balancer)
3. Application Layer (API Servers, Services)
4. Data Layer (Databases, Caches, Queues)
5. External Services (Payment, Email, SMS)
4. API Design
RESTful API Example:
GET /api/v1/users
POST /api/v1/users
GET /api/v1/users/{id}
PUT /api/v1/users/{id}
DELETE /api/v1/users/{id}
Consider:
- Versioning strategy
- Authentication/Authorization
- Rate limiting
- Pagination
- Error handling
- HATEOAS (optional)
5. Data Model Design
Considerations:
- Normalized vs Denormalized
- SQL vs NoSQL
- Partitioning strategy
- Indexing strategy
- Data retention policy
- Backup and recovery
Common System Designs
1. URL Shortener
Requirements:
- Shorten long URLs
- Redirect to original URL
- Track analytics
- Handle 100M URLs
- 100:1 read/write ratio
Design:
┌─────────┐ ┌──────────────┐ ┌──────────┐
│ Client │─────▶│ Load Balancer│─────▶│ API Server│
└─────────┘ └──────────────┘ └─────┬────┘
│
┌────────────────────┼────────────┐
│ │ │
┌────▼────┐ ┌─────▼─────┐ ┌───▼────┐
│ Cache │ │ Database │ │Analytics│
│ (Redis) │ │(PostgreSQL│ │(ClickHouse)│
└─────────┘ └───────────┘ └────────┘
Key Design Decisions:
- Base62 encoding for short codes
- Redis for caching hot URLs
- PostgreSQL for persistence
- Separate analytics database
- Rate limiting per user
2. Social Media Feed
Requirements:
- Post creation and display
- Follow/unfollow users
- Timeline generation
- 500M users
- Sub-second feed load time
Design:
┌─────────┐ ┌──────────┐ ┌───────────┐
│ Mobile │────▶│ CDN │────▶│ API GW │
└─────────┘ └──────────┘ └─────┬─────┘
│
┌────────────────────────┼──────────────┐
│ │ │
┌─────▼─────┐ ┌──────▼──────┐ ┌────▼────┐
│ User Svc │ │ Post Svc │ │Feed Svc │
└─────┬─────┘ └──────┬──────┘ └────┬────┘
│ │ │
┌─────▼─────┐ ┌──────▼──────┐ ┌────▼────┐
│ User DB │ │ Post DB │ │ Cache │
│(PostgreSQL│ │ (Cassandra) │ │(Redis) │
└───────────┘ └─────────────┘ └─────────┘
Key Design Decisions:
- Fan-out on write for small followings
- Fan-out on read for celebrities
- Cassandra for time-series data
- Redis for pre-computed feeds
- Separate microservices
3. E-Commerce Platform
Microservices Architecture:
┌────────────────────────────────────────────────────┐
│ API Gateway │
└─────┬──────┬──────┬──────┬──────┬──────┬─────────┘
│ │ │ │ │ │
┌──▼──┐┌──▼──┐┌──▼──┐┌──▼──┐┌──▼──┐┌──▼──┐
│User ││Prod ││Cart ││Order││Pay ││Inv │
│ Svc ││ Svc ││ Svc ││ Svc ││ Svc ││ Svc │
└──┬──┘└──┬──┘└──┬──┘└──┬──┘└──┬──┘└──┬──┘
│ │ │ │ │ │
┌──▼──────▼──────▼──────▼──────▼──────▼──┐
│ Message Queue (RabbitMQ) │
└────────────────────────────────────────┘
│ │ │ │ │ │
┌──▼──┐┌──▼──┐┌──▼──┐┌──▼──┐┌──▼──┐┌──▼──┐
│User ││Prod ││Cart ││Order││Pay ││Inv │
│ DB ││ DB ││Cache││ DB ││Logs ││ DB │
└─────┘└─────┘└─────┘└─────┘└─────┘└─────┘
Event Flow:
1. User places order → OrderCreated event
2. Payment Service → PaymentProcessed event
3. Inventory Service → ItemsReserved event
4. Notification Service → OrderConfirmed email
Architecture Patterns
1. Microservices
Pros:
- Independent deployment
- Technology diversity
- Scalability
- Fault isolation
Cons:
- Complexity
- Distributed system challenges
- Network latency
- Data consistency
2. Event-Driven Architecture
Components:
- Event Producers
- Event Bus (Kafka, RabbitMQ)
- Event Consumers
- Event Store
Benefits:
- Loose coupling
- Asynchronous processing
- Scalability
- Audit trail
3. CQRS (Command Query Responsibility Segregation)
Write Side: Read Side:
┌─────────┐ ┌─────────┐
│ Command │ │ Query │
│ Handler │ │ Handler │
└────┬────┘ └────┬────┘
│ │
┌────▼────┐ ┌────▼────┐
│ Write │ Events │ Read │
│ DB │────────────▶│ DB │
└─────────┘ └─────────┘
4. Hexagonal Architecture (Ports & Adapters)
┌──────────────────────┐
│ Application Core │
│ (Business Logic) │
└──────────┬───────────┘
│
┌──────────┴───────────┐
│ │
┌────▼────┐ ┌────▼────┐
│ Ports │ │ Ports │
│ (API) │ │ (SPI) │
└────┬────┘ └────┬────┘
│ │
┌────▼────┐ ┌────▼────┐
│Adapters │ │Adapters │
│(HTTP, │ │(DB, │
│ gRPC) │ │ Queue) │
└─────────┘ └─────────┘
Database Selection Guide
SQL (PostgreSQL, MySQL)
Use When:
- ACID compliance required
- Complex joins and relationships
- Data integrity is critical
- Well-defined schema
NoSQL Document (MongoDB)
Use When:
- Flexible schema
- Hierarchical data
- Rapid development
- Horizontal scaling
NoSQL Key-Value (Redis, DynamoDB)
Use When:
- Simple key-based lookups
- Caching
- Session storage
- High-speed access
NoSQL Wide-Column (Cassandra, HBase)
Use When:
- Time-series data
- Write-heavy workloads
- Massive scale
- High availability
NoSQL Graph (Neo4j)
Use When:
- Relationship-heavy data
- Social networks
- Recommendation engines
- Fraud detection
Performance Optimization
Caching Strategies
1. Cache-Aside (Lazy Loading)
- App checks cache first
- On miss, load from DB and cache
- Use for: Read-heavy workloads
2. Write-Through
- Write to cache and DB together
- Use for: Data consistency
3. Write-Behind
- Write to cache first, DB later
- Use for: Write-heavy workloads
4. Refresh-Ahead
- Proactively refresh cache
- Use for: Predictable access patterns
CDN Strategy
- Static assets (images, CSS, JS)
- Geographic distribution
- Edge caching
- Reduced origin server load
Database Optimization
- Proper indexing
- Query optimization
- Connection pooling
- Read replicas
- Partitioning/Sharding
Security Considerations
Authentication & Authorization
- JWT tokens
- OAuth 2.0
- Role-based access control (RBAC)
- Principle of least privilege
Data Protection
- Encryption at rest
- Encryption in transit (TLS)
- Sensitive data masking
- PII compliance
API Security
- Rate limiting
- Input validation
- CORS configuration
- API keys/tokens
Infrastructure Security
- Network segmentation
- Firewalls
- DDoS protection
- Security groups
Monitoring & Observability
The Three Pillars
Metrics
- Response time (p50, p95, p99)
- Error rate
- Request rate
- Resource utilization
Logs
- Structured logging
- Centralized logging (ELK)
- Log levels
- Correlation IDs
Traces
- Distributed tracing
- Request flow visualization
- Bottleneck identification
- Service dependencies
Best Practices
- Start Simple - Don't over-engineer
- Design for Failure - Assume components will fail
- Eventual Consistency - Accept when appropriate
- Idempotency - Make operations repeatable safely
- API Versioning - Plan for changes
- Documentation - Keep architecture docs updated
- Cost Optimization - Consider operational costs
- Testing Strategy - Unit, integration, E2E tests
Architecture Decision Records (ADR)
Template:
# ADR-001: Use PostgreSQL for Primary Database
## Status
Accepted
## Context
We need a reliable database for our e-commerce platform
handling transactions and user data.
## Decision
We will use PostgreSQL as our primary database.
## Consequences
Pros:
- ACID compliance
- Strong consistency
- Mature ecosystem
Cons:
- Vertical scaling limits
- Complex sharding setup
## Alternatives Considered
- MongoDB - rejected due to consistency requirements
- MySQL - rejected due to PostgreSQL's better JSON support
This skill ensures well-architected, scalable, and maintainable systems designed for long-term success.