System Design
System design is the process of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements. It is the bridge between business requirements and the actual software implementation.
1. Core Goals
When designing a system, we typically aim for three main objectives:
- Reliability: The system should continue to work correctly even in the face of adversity (hardware faults, software bugs, human error).
- Scalability: As the system grows (in data volume, traffic volume, or complexity), there should be reasonable ways to deal with that growth.
- Maintainability: Over time, many different people will work on the system (engineering and operations). It should be productive for them to do so.
2. High-Level Architecture
Most modern web systems follow a tiered architecture:
- Presentation Layer (Client): The user interface (Web, Mobile).
- Application Layer (Service): The business logic (API, Microservices).
- Data Layer (Persistence): Where data is stored (SQL, NoSQL, Cache).
3. Key Components
- Load Balancers: Distribute incoming traffic across multiple servers.
- Databases: Store persistent data.
- Caches: Store frequently accessed data in memory for speed.
- Message Queues: Allow asynchronous communication between services.
- CDN (Content Delivery Network): Serve static assets from locations close to the user.
4. Design Considerations
- Data Consistency: Do we need strong consistency (Banking) or eventual consistency (Social Media)?
- Data Partitioning: How do we split data when it becomes too big for one server? (Sharding).
- Failure Handling: What happens if a database node dies? (Replication, Failover).
5. Vertical vs Horizontal Scaling
Vertical Scaling (Scaling Up)
Adding more power (CPU, RAM, Disk) to an existing server.
- Pros: Simple (no code changes required).
- Cons: Hardware limits (you hit a ceiling), single point of failure, expensive.
Horizontal Scaling (Scaling Out)
Adding more servers to the pool of resources.
- Pros: Theoretically infinite scaling, redundancy (if one server dies, others take over).
- Cons: Complex (requires load balancing, data partitioning, distributed consistency).
6. Latency vs Throughput
Understanding the difference between latency and throughput is crucial for performance optimization.
- Latency: The time it takes to perform a single operation (e.g., "It takes 200ms to load the homepage"). It is a measure of delay.
- Throughput: The number of operations the system can handle per unit of time (e.g., "The system handles 5,000 requests per second"). It is a measure of capacity.
Analogy:
- Latency: How fast a car travels on the highway.
- Throughput: How many cars pass a specific point on the highway per hour.
7. Availability vs Reliability
These two terms are often confused but represent different aspects of system health.
- Availability: The percentage of time the system is operational and accessible to users. It is often measured in "nines" (e.g., 99.99% availability).
- Focus: Uptime. "Is the system up right now?"
- Reliability: The probability that the system will perform its intended function without failure for a specific period.
- Focus: Correctness. "Is the system doing what it's supposed to do correctly?"
Example: A system that crashes every hour but restarts instantly (within 1ms) has high Availability (it's almost always up) but low Reliability (it fails constantly).
8. SLA, SLO, and SLI
These acronyms define the reliability guarantees of a service.
- SLA (Service Level Agreement): An agreement between the service provider and the customer. It defines the level of service expected and the penalties if that level is not met (e.g., "99.9% uptime or we refund 10% of your bill").
- SLO (Service Level Objective): A target value or range of values for a service level that is measured by an SLI. It is an internal goal (e.g., "We aim for 99.95% uptime").
- SLI (Service Level Indicator): A carefully defined quantitative measure of some aspect of the level of service that is provided (e.g., "Request Latency", "Error Rate", "System Throughput").
Relationship: SLI is the metric (the ruler). SLO is the goal (the line on the ruler). SLA is the contract (what happens if you miss the line).
9. Disaster Recovery
Disaster Recovery (DR) involves a set of policies, tools, and procedures to enable the recovery or continuation of vital technology infrastructure and systems following a natural or human-induced disaster.
Key Metrics
- RTO (Recovery Time Objective): The maximum acceptable length of time that your application can be offline. (e.g., "We must be back up within 4 hours").
- RPO (Recovery Point Objective): The maximum acceptable amount of data loss measured in time. (e.g., "We can lose up to 15 minutes of data").
Common Strategies
- Backup and Restore: Data is backed up to tape or cloud storage. Slowest recovery (High RTO), cheapest.
- Pilot Light: A minimal version of the environment is always running in the cloud. Database is replicated, but app servers are off until needed.
- Warm Standby: A scaled-down version of a fully functional environment is always running. Faster recovery than Pilot Light.
- Multi-Site Active/Active: Traffic is distributed across multiple regions. If one fails, traffic is routed to the others. Near-zero RTO/RPO, most expensive.
programming/system-design-interview-basics programming/distributed-systems programming/microservices-architecture programming/database-basics