EP 6.3: Master-Slave Architecture

1. HOW IT WORKS? ## The Master (The Leader) ## The Slaves (The Followers) ## 2. Replication Methods ## 3. Why Use It? - Advs :) ## 4. The Challenges - Dis Advs :( ## 5. Real-World Examples ## A. Relational Databases (MySQL/PostgreSQL) ## B. Redis (Caching) ## C. Distributed File Systems (HDFS) In system design, the Master-Slave (or Leader-Follower) architecture is one of the most fundamental patterns used to achieve scalability and high availability, particularly in database systems. :) Consider it like a leader asking its followers to do something and the followers comply with it. At its core, it is a model of communication where one device or process (the Master) has unidirectional control over one or more other devices or processes (the Slaves). In a data-driven application, this architecture separates the writing of data from the reading of data. Basically, Master commands and the Slave Follows, like followers can be a lot, there can be a lot of slaves for one master. To understand the "in-depth" side, you have to look at how data actually moves from Master to Slave: Asynchronous Replication: The Master writes the data, sends a success message to the user immediately, and then sends the data to Slaves in the background. Pro: Very fast performance. Con: If the Master crashes before the data hits the Slaves, that data might be lost (Replication Lag). Semi-Synchronous: The Master waits for at least one Slave to acknowledge the update before finishing. A typical e-commerce site uses Master-Slave. When you update your profile (Write), it hits the Master. When you browse products (Read), the app queries one of the many Slaves. Redis uses this to ensure that if the primary cache node goes down, the data isn't lost from memory. Slaves provide high-speed read access to cached objects. In the Hadoop Distributed File System, the NameNode acts as the Master (holding the metadata/map of where files are), while DataNodes act as Slaves (storing the actual chunks of data). SO now finally, you can use the MASTER-SLAVE ARCHITECTURE Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - Source of Truth: The Master handles all Write operations (INSERT, UPDATE, DELETE). - Coordination: Records these changes in a log. - Propagation: Resp. for pushing changes to Slaves so that they are i sync. - Read-Only: Generally restricted to Read operations. - Data Replication: They constantly pull or receive updates. - Scalability: Add as many slaves as per the traffic. - Synchronous Replication: The Master waits for all Slaves to confirm they have written the data before telling the user the "Write" was successful. - Pro: Zero data loss. - Con: High latency (the system is only as fast as its slowest Slave). - Asynchronous Replication: The Master writes the data, sends a success message to the user immediately, and then sends the data to Slaves in the background. Pro: Very fast performance. Con: If the Master crashes before the data hits the Slaves, that data might be lost (Replication Lag). - Semi-Synchronous: The Master waits for at least one Slave to acknowledge the update before finishing. - Read Scalability: If your app is "read-heavy" (like Twitter, where millions read a tweet but only one person writes it), you can spin up 10 Slaves to handle the load. - High Availability: If a Slave dies, the system stays up. If the Master dies, one of the Slaves can be "promoted" to be the new Master. - Analytic Isolation: You can run heavy, slow analytical queries on a Slave without slowing down the Master that is busy handling live user transactions. - Backups: You can pause a Slave to take a full database backup without affecting the live performance of the Master. - Eventual Consistency: Because of replication lag, a user might write data to the Master and immediately try to read it from a Slave, but see the "old" data because the update hasn't arrived yet. - Write Bottleneck: You can only have one Master for writes. If your app has massive write traffic (like a high-frequency trading bot), a single Master becomes a bottleneck. - Failover Complexity: Promoting a Slave to a Master during a crash requires complex logic (often handled by tools like Sentinel or Zookeeper) to ensure no data is corrupted or "Split-Brain" scenarios occur.