Database Management System (DBMS) / Cap theorem and Master Slave Architecture

Master Slave Architecture in DBMS

Master-Slave Architecture is a replication setup where:

  • One master (primary) node handles all write operations.

  • One or more slave (secondary/replica) nodes handle read-only queries and replicate data from the master.

✅ Writes go to Master

✅ Reads go to Slaves (for load distribution)

🔁 Slaves sync with Master periodically or in real-time

🔁 Diagram Overview

⚙️ How It Works

Operation Type

Performed By

Notes

INSERT/UPDATE/DELETE

Master

Only master can modify data

SELECT/READ

Slaves (or Master)

Slaves can reduce load on master

Replication

Master → Slaves

Asynchronous or Synchronous

🟢 Advantages

Benefit

Explanation

✅ Improved Read Performance

Multiple slaves can handle read-heavy workloads

✅ Backup & Redundancy

Slaves can be used as backups or failovers

✅ Simplified Writes

Only one node handles writes, so no write conflicts

✅ Horizontal Read Scaling

Add more slaves to support more read clients

🔴 Disadvantages

Limitation

Impact

❌ Single Point of Failure (SPoF)

If master fails, writes stop (unless failover configured)

❌ Replication Lag

Slaves may lag behind the master (eventual consistency)

❌ No Write Scaling

Only one master; can't scale write operations easily

❌ Complex Failover

Promoting a slave to master requires coordination and possible downtime

🧩 Use Cases

Use Case

Reason

📘 Content-heavy websites

Most operations are read-heavy

📈 Analytics dashboards

Run heavy reads on slaves without overloading the master

🛒 E-commerce product pages

Customers read from slaves; checkout writes to master

💾 Database backup systems

Backups can be taken from slaves without affecting production writes

🔄 Synchronous vs Asynchronous Replication

Mode

Description

Pros

Cons

🔁 Synchronous

Slaves acknowledge data before master confirms write

Strong consistency

Slower performance

🕒 Asynchronous

Master confirms write immediately; slaves catch up later

Faster performance

Possibility of stale reads or data loss during failover

🛠️ Real-World Systems Using It

Database

Notes

✅ MySQL

Has native master-slave replication

✅ PostgreSQL

Supports streaming replication

✅ MongoDB

Primary-Secondary model (similar to master-slave)

✅ Redis

Master-slave replication for performance and HA

✅ SQL Server

Supports log shipping and transactional replication

✅ Summary

Feature

Master-Slave

✅ Write Scalability

❌ No (single master)

✅ Read Scalability

✅ Yes (multiple slaves)

✅ Fault Tolerance

✅ Partial (if failover configured)

✅ Consistency

❌ Weak (if async), ✅ Strong (if sync)

✅ Use Case Fit

Read-heavy workloads, backup, redundancy