Data Consistency and Tradeoffs in Distributed Systems

About this video

### Comprehensive Final Summary The document provides a detailed exploration of the challenges and solutions involved in maintaining **consistency** in distributed systems, with a focus on the trade-offs between consistency, availability, and performance. Below is a comprehensive summary of the key points: --- #### **1. Importance of Consistency** Consistency ensures that multiple copies of data across distributed systems remain synchronized, which is critical for reliable operations. It plays a central role in contexts such as the **CAP theorem** (Consistency, Availability, Partition Tolerance) and **database transactions**, where maintaining accurate and up-to-date data is essential. --- #### **2. Challenges with Single Server Systems** Initially, systems like Facebook relied on a single server (e.g., at Harvard), but this approach introduced significant limitations: - **Single Point of Failure**: If the server failed, the entire system became unavailable. - **Vertical Scaling Limit**: There is a physical and financial limit to how much a single server can be scaled, eventually necessitating expensive supercomputers. - **High Latency**: Users geographically distant from the server (e.g., Oxford students accessing a Harvard server) experienced slow response times due to network delays. These issues highlighted the need for a distributed architecture to improve scalability, reliability, and performance. --- #### **3. Transition to Multiple Servers** To address the shortcomings of single-server systems, Facebook introduced multiple servers in different locations (e.g., Harvard and Oxford). However, this approach introduced new challenges: - **No Data Sharing**: Each server stored only local data, limiting cross-region user interactions. - **Latency and Single Point of Failure Persist**: While adding servers improved redundancy, latency remained an issue for users accessing distant servers, and the failure of a critical server could still disrupt service. --- #### **4. Caching as a Partial Solution** Caching popular data locally (e.g., caching Oxford profiles in Harvard) reduced latency by minimizing the need to fetch data from distant servers. However, this solution was incomplete because: - Cache misses could still occur, requiring fallback to slower remote data retrieval. --- #### **5. Data Replication for Resilience** Storing multiple copies of data across servers addressed several key issues: - **Single Point of Failure**: If one server crashed, another could take over, improving fault tolerance. - **Network Issues**: Local copies ensured data availability during network outages. - **Latency**: Faster access to data was achieved since users could retrieve it from nearby servers. However, this approach introduced a new challenge: ensuring **consistency** across all data copies. --- #### **6. Consistency Challenges** Maintaining consistency across multiple data copies is inherently complex: - **Manual Updates**: Infrequent updates could be managed manually, but this approach is impractical for real-time systems like Facebook. - **TCP for Reliable Updates**: TCP protocols can reliably propagate updates between servers, but network failures or server downtime can disrupt acknowledgments. - **Two Generals Problem**: Achieving guaranteed consistency between servers is theoretically impossible due to potential network failures, making it difficult to ensure both servers commit an update simultaneously. --- #### **7. Leader-Follower Model** To simplify consistency management, the **leader-follower model** was introduced: - A **leader server** (e.g., U.S. server) handles all write operations, while **follower servers** handle read operations. - **Inconsistency Risks**: If updates fail to propagate to followers, reads may return inconsistent data. - **Availability vs. Consistency Trade-off**: This model often prioritizes consistency over availability, as read/write operations may be blocked until acknowledgments are received, ensuring all nodes reflect the same data. --- #### **8. Handling Transaction Failures** The document delves into the complexities of handling transaction failures in distributed systems: - **Timeouts and Rollbacks**: If a commit message fails, the system assumes a transaction failure and rolls back after a timeout. Followers cannot independently roll back without instructions from the leader. - **Retries and Transaction IDs**: Retries are used to ensure commits are acknowledged, relying on unique transaction IDs to prevent side effects and maintain consistency. - **Cost of Strong Consistency**: While this approach guarantees **strong consistency**—ideal for systems like financial applications—it comes at high costs in terms of **availability**, **performance**, and **infrastructure**. --- #### **9. Eventual Consistency as an Alternative** To balance responsiveness and consistency, **eventual consistency** is proposed as an alternative: - **Temporary Discrepancies**: Eventual consistency allows temporary inconsistencies between data copies, which resolve over time. - **Prioritizing Responsiveness**: This model prioritizes system availability and low-latency responses over immediate consistency, making it suitable for applications where slight delays in data synchronization are acceptable (e.g., social media platforms). --- #### **10. Key Trade-offs** The document highlights the fundamental trade-offs between consistency models:

Course: System Design Playlist

**Course Description: System Design Playlist** This comprehensive course, titled "System Design Playlist," is designed to provide students with a deep understanding of system design principles and practices through real-world analogies and technical explanations. The course begins by using the analogy of running a pizza restaurant to illustrate fundamental concepts in system design, such as optimizing processes, scaling resources, and ensuring resilience. Students will learn about vertical scaling—enhancing the capabilities of existing resources—and horizontal scaling—adding more resources to distribute the workload. Through this engaging example, participants will grasp essential strategies for improving throughput, eliminating single points of failure, and implementing backup systems to maintain operational continuity. As the course progresses, students will delve into advanced topics like microservice architecture, where responsibilities within a system are clearly defined and divided among specialized teams or services. This approach allows for efficient scaling and management of different components based on their specific needs. Additionally, the course covers distributed systems, highlighting the importance of fault tolerance and quick response times by strategically placing servers closer to users. Concepts such as load balancing, which intelligently routes requests to optimize performance, and decoupling systems to enhance flexibility and adaptability, are thoroughly explored. Participants will also learn about logging and metrics to monitor system health and make informed decisions. The course wraps up by contrasting high-level system design, which focuses on overarching architectural decisions, with low-level system design, which deals with the actual coding and implementation details. By mapping business scenarios to technical solutions, students will gain insights into designing scalable, reliable, and extensible systems. Whether you're new to system design or looking to deepen your expertise, this course equips you with the knowledge and tools needed to tackle complex design challenges and develop robust systems capable of meeting diverse user demands.