Design_basics
Chapter 2: System Design Basics & Principles
Section titled “Chapter 2: System Design Basics & Principles”Core Principles for Building Scalable Systems
Section titled “Core Principles for Building Scalable Systems”2.1 Design Principles Overview
Section titled “2.1 Design Principles Overview”Building scalable systems requires adherence to fundamental principles that guide architectural decisions.
System Design Principles =======================
+-------------+ +-------------+ +-------------+ | Simplicity | --> | Modularity | --> | Loose | | | | | | Coupling | +-------------+ +-------------+ +-------------+ | | | v v v +-------------+ +-------------+ +-------------+ | High | --> | Single | --> | Fail | | Cohesion | | Responsibility| Safe | +-------------+ +-------------+ +-------------+2.2 SOLID Principles in System Design
Section titled “2.2 SOLID Principles in System Design”2.2.1 Single Responsibility Principle (SRP)
Section titled “2.2.1 Single Responsibility Principle (SRP)”Each component should have one reason to change:
Before: God Class ==================
+---------------------------------------+ | UserManager | +---------------------------------------+ | - authenticate() | | - sendEmail() | | - processPayment() | | - generateReport() | +---------------------------------------+ | v
After: Separated Responsibilities ==================================
+------------+ +------------+ +------------+ | Auth | | Email | | Payment | | Service | | Service | | Service | +------------+ +------------+ +------------+ | | | +------------------+----------------+ v +------------+ | Report | | Service | +------------+2.2.2 Open/Closed Principle (OCP)
Section titled “2.2.2 Open/Closed Principle (OCP)”Software entities should be open for extension, closed for modification:
Open/Closed Principle =====================
Before: Modify existing code +--------------------------+ | PaymentProcessor | | - processCreditCard() | Adding new payment = editing this | - processPayPal() | +--------------------------+
After: Extend without modification +--------------------------+ | <<interface>> | | PaymentMethod | +--------------------------+ ^ | +-------+-------+-------+ | | | | +----+ +----+ +----+ +----+ |Credit| |Pay | |Bank| |... | |Card | |Pal | |Transfer| +----+ +----+ +----+ +----+2.2.3 Liskov Substitution Principle (LSP)
Section titled “2.2.3 Liskov Substitution Principle (LSP)”Objects of a superclass should be replaceable with subclass objects:
Liskov Substitution ==================
+------------------------+ | <<interface>> | | Bird | +------------------------+ | + fly() | | + eat() | +------------------------+ ^ | +--------+--------+ | | +----+ +----+ |Duck | |Penguin| +----+ +----+ | | v v Can fly Cannot fly! (OK) (Violates LSP)
Fix: Break into interfaces ==========================
+------------+ +------------+ | Flying | | NonFlying | | Bird | | Bird | +------------+ +------------+2.2.4 Interface Segregation Principle (ISP)
Section titled “2.2.4 Interface Segregation Principle (ISP)”Prefer small, specific interfaces over large ones:
Interface Segregation =====================
Fat Interface (Bad) +---------------------------+ | Machine | +---------------------------+ | + print() | | + fax() | | + scan() | +---------------------------+ | v
Segregated Interfaces (Good) +------------+ +------------+ +------------+ | Printer | | Fax | | Scanner | +------------+ +------------+ +------------+2.2.5 Dependency Inversion Principle (DIP)
Section titled “2.2.5 Dependency Inversion Principle (DIP)”Depend on abstractions, not concrete implementations:
Dependency Inversion =====================
Before: Direct dependency +--------+ +----------+ | Client | --------> | MySQL | +--------+ | Database | +----------+
After: Depend on abstraction +--------+ +------------+ +----------+ | Client | --------> | Repository | --------> | MySQL | +--------+ +----| Interface | | Database | | +------------+ +----------+ | ^ | | | +----------+ +-------- | PostgreSQL| +----------+2.3 Key Design Principles
Section titled “2.3 Key Design Principles”2.3.1 KISS (Keep It Simple, Stupid)
Section titled “2.3.1 KISS (Keep It Simple, Stupid)”Simplicity should be a design goal:
Complexity vs Simplicity =========================
Complex Design Simple Design +-------------+ +-------------+ | 15 layers | | 3 layers | | 50+ classes| | 10 classes | | Complex | | Clear | | inheritance| | separation | +-------------+ +-------------+ | | v v Hard to maintain Easy to understand Hard to test Easy to test Expensive to change Cheap to change2.3.2 DRY (Don’t Repeat Yourself)
Section titled “2.3.2 DRY (Don’t Repeat Yourself)”Every piece of knowledge should have a single representation:
DRY Principle =============
Violation (WET - Write Everything Twice) =========================================
UserService OrderService PaymentService +----------+ +----------+ +----------+ | validate | | validate | | validate | | email | | email | | email | +----------+ +----------+ +----------+ | | | +-----------------+-----------------+ | v Code is duplicated!
Following DRY =============
+------------+ +------------+ +------------+ | User | | Order | | Payment | | Service | | Service | | Service | +------------+ +------------+ +------------+ | | | +-------------------+-------------------+ | v +------------------+ | Validation | | Helper | +------------------+2.3.3 YAGNI (You Aren’t Gonna Need It)
Section titled “2.3.3 YAGNI (You Aren’t Gonna Need It)”Don’t build features until they’re necessary:
YAGNI Principle ===============
Before (Over-engineering) +-------------------------+ | UserService | | - createUser() | | - updateUser() | <- Built "just in case" | - deleteUser() | | - exportToPDF() | <- Not needed yet! | - importFromCSV() | +-------------------------+
After (Build what you need) +-------------------------+ | UserService | | - createUser() | | - getUser() | +-------------------------+ Add features when actually needed2.3.4 Separation of Concerns (SoC)
Section titled “2.3.4 Separation of Concerns (SoC)”Different concerns should be in different modules:
Separation of Concerns ======================
+-----------------------------------------------------------+ | Application | +-----------------------------------------------------------+ | +-----------+ +-----------+ +-----------+ | | | UI | | Business | | Data | | | | Layer | | Logic | | Access | | | +-----------+ +-----------+ +-----------+ | | | | | | | v v v | | +----------------------------------------------+ | | | Infrastructure | | | | +----------+ +----------+ +----------+ | | | | | Web | | Database| | Cache | | | | | | Server | | | | | | | | | +----------+ +----------+ +----------+ | | | +-----------------------------------------------------+| +-----------------------------------------------------------+2.4 Architectural Patterns
Section titled “2.4 Architectural Patterns”2.4.1 Layered Architecture
Section titled “2.4.1 Layered Architecture” Layered Architecture ===================
+-------------------------+ | Presentation Layer | (UI, Controllers) +-------------------------+ | v +-------------------------+ | Application Layer | (Use Cases, Services) +-------------------------+ | v +-------------------------+ | Domain Layer | (Business Logic, Entities) +-------------------------+ | v +-------------------------+ | Infrastructure Layer | (Database, External APIs) +-------------------------+
Communication Flow =================
Request: UI -> Application -> Domain -> Infrastructure Response: Infrastructure -> Domain -> Application -> UI2.4.2 Client-Server Architecture
Section titled “2.4.2 Client-Server Architecture” Client-Server Model ===================
Client(s) Server +--------------+ +---------------+ | | Request | | | Browser/ | ---------> | Application| | Mobile App | | Server | | | <--------- | | +--------------+ Response+---------------+ | v
Multi-Tier Architecture ======================
+-----------+ +-----------+ +-----------+ | Client | --> | Web/API | --> | Database | | Tier | | Tier | | Tier | +-----------+ +-----------+ +-----------+2.4.3 Event-Driven Architecture
Section titled “2.4.3 Event-Driven Architecture” Event-Driven Architecture =========================
+--------+ +---------+ +-----------+ +----------+ | Event | | Event | | Event | | Event | |Producer| --> | Bus | --> | Processor| --> | Consumer | +--------+ +---------+ +-----------+ +----------+
Example Flow ============
User Signs Up Event Bus Handlers +-----------+ +---------+ +------------+ | | New | | | | | User | -----> | Kafka/ | -----> | Send Email | | Service | User | RabbitMQ| | Create Pro | +-----------+ +---------+ | file | +----------+ | | | +---------+------------+ v +--------------------+ | Welcome Email | +--------------------+2.5 Design for Failure
Section titled “2.5 Design for Failure”The Mindset
Section titled “The Mindset” Everything Fails ================
Hardware fails Software fails Network fails +------------+ +------------+ +------------+ | Disk full | | Memory | | Timeout | | RAM error | | leak | | Packet loss| | Power down | | Deadlock | | DNS fail | +------------+ +------------+ +------------+
Design Principles for Failure =============================
1. Assume failure will happen 2. Build redundancy at every level 3. Design for graceful degradation 4. Implement proper monitoring 5. Plan for recoveryStrategies
Section titled “Strategies”| Strategy | Description |
|---|---|
| Redundancy | Multiple copies of data/services |
| Replication | Copy data across nodes |
| Isolation | Contain failure to one area |
| Recovery | Automatic or manual recovery |
| Monitoring | Detect failures quickly |
2.6 Design Checklist
Section titled “2.6 Design Checklist”Before finalizing your design, verify:
Requirements
Section titled “Requirements”- Have you clarified the scale?
- Are functional requirements clear?
- Are non-functional requirements defined?
- Have you identified constraints?
Architecture
Section titled “Architecture”- Is the architecture appropriate for the use case?
- Are components loosely coupled?
- Is there clear separation of concerns?
- Have you chosen the right data stores?
Scalability
Section titled “Scalability”- Can the system scale horizontally?
- Is there a clear scaling strategy?
- Are there any single points of failure?
- Is the database properly scaled?
Reliability
Section titled “Reliability”- How does the system handle failures?
- Is there proper error handling?
- Are there retry mechanisms?
- Is there proper logging?
Security
Section titled “Security”- Is data encrypted at rest and in transit?
- Is there proper authentication/authorization?
- Are there rate limiting mechanisms?
- Is sensitive data properly protected?
Summary
Section titled “Summary”Key principles to remember:
- Keep it simple - Complexity is the enemy
- Single responsibility - Do one thing well
- Design for failure - Expect things to break
- Separate concerns - Clear boundaries
- Program to interfaces - Depend on abstractions
- Don’t over-engineer - Build what you need