# 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:

1.  **Presentation Layer (Client):** The user interface (Web, Mobile).
2.  **Application Layer (Service):** The business logic (API, Microservices).
3.  **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
1.  **Backup and Restore:** Data is backed up to tape or cloud storage. Slowest recovery (High RTO), cheapest.
2.  **Pilot Light:** A minimal version of the environment is always running in the cloud. Database is replicated, but app servers are off until needed.
3.  **Warm Standby:** A scaled-down version of a fully functional environment is always running. Faster recovery than Pilot Light.
4.  **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]]