System Design flashcards, generated for you.

The ability of a system to handle increased load (users, data, requests) by adding resources. Measured by how performance degrades as load increases. Vertical scaling adds resources to one machine; horizontal scaling adds more machines.

Latency: time for a single request to complete (e.g., 100ms). Throughput: number of requests processed per unit time (e.g., 1000 req/sec). Low latency ≠ high throughput; a system can have low latency but low throughput if it processes requests serially.

Consistency: all nodes see the same data simultaneously. Availability: system remains operational despite failures. Partition tolerance: system functions despite network partitions. CAP states you can guarantee only 2 of 3 in a distributed system.

Strong consistency prioritizes correctness (all clients see latest data) but requires blocking during network partitions, reducing availability. Eventual consistency prioritizes availability (always responsive) but clients may temporarily see stale data. Example: banking (strong consistency) vs. social media feeds (eventual consistency).

A load balancer distributes incoming requests across multiple servers to prevent overload and ensure reliability. Common algorithms: Round Robin (rotate servers sequentially), Least Connections (route to least-busy server), IP Hash (consistent routing by client IP), Weighted Round Robin (favor higher-capacity servers).

Sharding: horizontally partition data across multiple databases by a key (e.g., user ID range). Increases write capacity and data volume handled. Trade-off: replication duplicates data across servers for fault tolerance and read scaling, but increases storage and consistency complexity. Sharding solves write scaling; replication solves read scaling and availability.

Storing frequently accessed data in fast memory (Redis, Memcached) to reduce latency and database load. Trade-offs: adds complexity (invalidation, staleness), increases memory cost, and requires cache-busting strategy. Risk: stale data if cache isn't invalidated; unused cached data wastes resources.

SQL: ACID transactions, structured schema, vertical scaling, strong consistency. Best for relational data and financial systems. NoSQL: eventual consistency, flexible schema, horizontal scaling, high throughput. Best for unstructured data, high volume, and high velocity. Trade-off: SQL safer but less scalable; NoSQL scalable but consistency is weaker.

A single entry point that routes requests to appropriate backend services, handling authentication, rate limiting, request transformation, and load balancing. Trade-offs: single point of failure (mitigated by redundancy), added latency (minimal), but provides security layer and decouples clients from service topology changes.

A guarantee that if no new updates occur, all replicas will converge to the same state eventually. Acceptable for non-critical reads (user feeds, analytics, product catalogs) where brief staleness is tolerable. Not acceptable for financial transactions, inventory counts, or security-critical data where immediate consistency is required.