Alright, let's tackle 1.d Key Concepts and Terminology. This is a huge part of preparing for system design interviews. You need to be fluent in the language of distributed systems. We'll build a glossary, and I'll explain each term. This is not an exhaustive list, but it covers the most important concepts for an L5 interview. We'll go into more detail on many of these in later phases.

Fundamental Concepts:

• Latency: The time it takes for a request to travel from the client to the server and back. Lower latency is generally better. Measured in milliseconds (ms) or seconds (s).
• Throughput: The amount of data processed or the number of requests handled per unit of time. Higher throughput is generally better. Measured in requests per second (RPS), bits per second (bps), etc.
• CAP Theorem (Brewer's Theorem): A fundamental theorem in distributed systems that states that it's impossible for a distributed data store to simultaneously provide more than two out of the following three guarantees:
  • Consistency: Every read receives the most recent write or an error.
  • Availability: Every request receives a (non-error) response, without the guarantee that it contains the most recent write.
  • Partition Tolerance: The system continues to operate despite network partitions (communication breakdowns between nodes).
  • In practice, you always have to assume partition tolerance in a distributed system, so you're choosing between Consistency and Availability.
• ACID (Atomicity, Consistency, Isolation, Durability): A set of properties that guarantee reliable processing of database transactions. Primarily associated with relational databases (SQL).
  • Atomicity: All operations in a transaction succeed or fail as a single unit.
  • Consistency: A transaction moves the database from one valid state to another.
  • Isolation: Concurrent transactions are isolated from each other, as if they were executed sequentially.
  • Durability: Once a transaction is committed, it remains so, even in the event of a system failure.
• BASE (Basically Available, Soft state, Eventually consistent): A philosophy often used in NoSQL databases that prioritizes availability over strong consistency.
  • Basically Available: The system is designed to be available most of the time.
  • Soft state: The state of the system may change over time, even without input.
  • Eventually consistent: The system will eventually become consistent, but there may be a period of inconsistency.

Core Components:

• Load Balancing: Distributing incoming network traffic across multiple servers to prevent any single server from becoming overloaded. Improves availability and responsiveness.
• Caching: Storing frequently accessed data in a temporary storage location (cache) to reduce latency and improve performance.
• Database: A structured collection of data. We'll cover SQL and NoSQL databases in detail later.
• Proxy Server: An intermediary server that sits between clients and other servers. Can be used for various purposes, including caching, security, and load balancing.
  • Forward Proxy: Acts on behalf of clients. Commonly used to bypass network restrictions or improve privacy.
  • Reverse Proxy: Acts on behalf of servers. Commonly used for load balancing, SSL encryption, and caching.
• API Gateway: A single entry point for external clients to access multiple services in a microservices architecture. Handles routing, authentication, rate limiting, and other cross-cutting concerns.
• Message Queue: A component that enables asynchronous communication between services. Services publish messages to the queue, and other services consume those messages. Improves decoupling and fault tolerance. (e.g., RabbitMQ, Kafka, SQS)

Architectural Patterns:

• Microservices: An architectural style that structures an application as a collection of small, independent services, each responsible for a specific business function.
• Monolith: A traditional architectural style where all components of an application are tightly coupled and deployed as a single unit.

Data Management:

• Replication: Copying data to multiple servers to improve availability and fault tolerance.
  • Master-Slave Replication: One server (the master) handles writes, and the changes are replicated to one or more slave servers, which handle reads.
  • Master-Master Replication: Multiple servers can handle writes, and the changes are replicated to all other servers.
• Sharding (Partitioning): Dividing a database into smaller, more manageable pieces (shards) that are distributed across multiple servers. Improves scalability and performance.
• Consistency (Strong vs. Eventual):
  • Strong Consistency: All clients see the same data at the same time.
  • Eventual Consistency: Clients may see stale data temporarily, but the system will eventually become consistent.

Other Important Terms:

• Idempotency: Making sure same request executed multiple times results in same output.
• Availability: Percentage of uptime.
• Redundancy: Having multiple instances of a component.

This is a starting point. We'll be revisiting these terms and adding more throughout the roadmap. Make sure you understand these concepts deeply. Don't just memorize definitions; understand why each concept is important and how it's used in real-world systems. Being able to use these terms correctly and confidently in an interview is crucial.