Master-Slave vs Master-Master Replication Interview Questions
Master Master-Slave vs Master-Master Replication with interview-focused questions covering architecture, read/write scaling, conflict resolution, failover, consistency, use cases, advantages, disadvantages, and enterprise production best practices.
Introduction
Replication architecture is one of the most important design decisions in distributed database systems.
Choosing the wrong replication architecture can lead to
- Poor Performance
- Data Conflicts
- Downtime
- Scaling Issues
- Data Loss
The two most common replication architectures are
- Master-Slave (Primary-Replica)
- Master-Master (Multi-Primary)
Understanding the advantages, disadvantages, and production use cases of both architectures is a common interview topic for Senior Java Developers, Database Engineers, and Solution Architects.
Replication Architecture Overview
flowchart TD
Replication --> Master-Slave
Replication --> Master-Master
1. What is Master-Slave Replication?
Answer
Master-Slave Replication consists of
- One Master (Primary)
- One or More Slaves (Replicas)
The Master accepts
- Reads
- Writes
The Slaves usually handle
- Read Operations
- Reporting
- Backup
- Failover
Master-Slave Architecture
flowchart LR
Application --> Master
Master --> Slave1["Slave 1"]
Master --> Slave2["Slave 2"]
Master --> Slave3["Slave 3"]
Slave1["Slave 1"] --> ReadQueries["Read Queries"]
Slave2["Slave 2"] --> ReadQueries["Read Queries"]
Slave3["Slave 3"] --> ReadQueries["Read Queries"]
2. How does Master-Slave Replication work?
Workflow
Application
↓
Write Request
↓
Master
↓
Replication
↓
Slaves
↓
Read Requests
3. What is Master-Master Replication?
Master-Master Replication allows
multiple database servers
to accept
both
- Reads
- Writes
Every Master replicates its changes to the other Masters.
Master-Master Architecture
flowchart LR
Application --> MasterA["Master A"]
Application --> MasterB["Master B"]
MasterA["Master A"]
<--> MasterB["Master B"]
4. Why is Master-Master Replication used?
Benefits
- High Availability
- Geographic Distribution
- Write Scalability
- Reduced Downtime
5. What is the biggest difference?
| Master-Slave | Master-Master |
|---|---|
| One Writer | Multiple Writers |
| Simple | Complex |
| No Write Conflicts | Possible Conflicts |
6. Which architecture is simpler?
Master-Slave
because
only one database
accepts writes.
There is no write conflict.
7. Which architecture provides better read scaling?
Master-Slave
supports multiple read replicas.
Example
Master
↓
Replica1
↓
Replica2
↓
Replica3
Applications distribute read traffic across replicas.
8. Which architecture provides write scaling?
Master-Master
because multiple servers
can process writes simultaneously.
Read Scaling vs Write Scaling
flowchart LR
Master-Slave --> ReadScaling["Read Scaling"]
Master-Master --> WriteScaling["Write Scaling"]
9. What are write conflicts?
Suppose
Master A
Updates Balance = 100
At the same time
Master B
Updates Balance = 120
Which value is correct?
Conflict resolution becomes necessary.
Conflict Example
Master A
Balance = 100
Master B
Balance = 120
↓
Conflict
10. How are conflicts resolved?
Common strategies
- Last Write Wins
- Timestamp Based
- Version Numbers
- Application Logic
- Manual Resolution
11. Why doesn't Master-Slave have write conflicts?
Only one Master
accepts writes.
Therefore
there is
only one source of truth.
12. Which architecture provides better consistency?
Master-Slave
because
writes occur
on only one server.
13. Which architecture is easier to maintain?
Master-Slave
because
- Simpler Configuration
- Easier Monitoring
- Easier Troubleshooting
14. Which architecture has higher availability?
Master-Master
because
both nodes
can continue serving writes
if one fails
(depending on implementation and quorum mechanisms).
15. What happens if the Master fails?
Master-Slave
Master Down
↓
Replica Promotion
↓
New Master
Failover
flowchart LR
MasterFailure["Master Failure"] --> ReplicaPromotionApplication["Replica Promotion --> Application"]
16. What happens if one Master fails?
Master-Master
continues using
the remaining Master.
No promotion is required.
17. Which architecture is used most often?
Master-Slave
because
it is
- Simpler
- Safer
- Easier to Operate
18. Which databases support Master-Slave?
Examples
- PostgreSQL
- MySQL
- Redis
- MongoDB
- SQL Server
- Oracle
19. Which databases support Master-Master?
Examples
- MySQL Group Replication
- PostgreSQL BDR
- Oracle RAC (shared-disk cluster rather than traditional master-master replication)
- CouchDB
- Cassandra (multi-primary architecture)
20. Banking Example
Transactions
↓
One Primary
↓
Multiple Replicas
↓
Read Statements
↓
High Consistency
Master-Slave is preferred.
21. E-Commerce Example
Product Search
↓
Master
↓
Five Read Replicas
↓
Millions of Searches
22. Global SaaS Example
US Region
↓
Master A
Europe
↓
Master B
↓
Regional Writes
Master-Master can reduce latency but requires conflict handling.
23. Airline Booking Example
Flight Search
↓
Replicas
↓
Fast Reads
↓
Booking
↓
Master
24. Social Media Example
Likes
↓
Regional Masters
↓
Global Synchronization
Master-Master may be used depending on platform architecture.
25. Analytics Example
Reporting
↓
Read Replica
↓
No Load
↓
Primary Database
26. Production Example
500 Million Users
↓
Master
↓
10 Replicas
↓
Read Traffic Distributed
↓
Primary Handles Writes
27. Common Problems in Master-Slave
- Replication Lag
- Master Failure
- Read-after-write inconsistency
- Replica Delay
- Failover Time
28. Common Problems in Master-Master
- Write Conflicts
- Split Brain
- Conflict Resolution
- Network Partitions
- Complex Monitoring
29. Master-Slave vs Master-Master
| Feature | Master-Slave | Master-Master |
|---|---|---|
| Writers | One | Multiple |
| Readers | Multiple | Multiple |
| Write Scaling | No | Yes |
| Read Scaling | Yes | Yes |
| Complexity | Low | High |
| Conflict Resolution | No | Yes |
| Availability | High | Very High |
| Maintenance | Easy | Difficult |
30. Which architecture should you choose?
Choose Master-Slave when
- Most traffic is reads
- Strong consistency is required
- Simplicity is important
- Banking Systems
- E-Commerce
Choose Master-Master when
- Global Writes
- Multi-Region Applications
- Write Availability is critical
- Conflict handling is acceptable
Architecture Comparison
flowchart LR
Master-Slave --> Simple
Master-Slave --> StrongConsistency["Strong Consistency"]
Master-Master --> WriteScaling["Write Scaling"]
Master-Master --> ConflictResolution["Conflict Resolution"]
Enterprise Best Practices
- Prefer Master-Slave for most enterprise applications.
- Use Read Replicas to scale reads.
- Keep only one write node unless multi-primary is required.
- Monitor replication lag continuously.
- Test failover procedures regularly.
- Avoid unnecessary multi-primary deployments.
- Implement conflict resolution carefully.
- Keep backups independent of replication.
- Monitor network latency between nodes.
- Document disaster recovery procedures.
Quick Revision
| Topic | Key Point |
|---|---|
| Master-Slave | One Writer |
| Master-Master | Multiple Writers |
| Read Scaling | Both |
| Write Scaling | Master-Master |
| Write Conflicts | Master-Master |
| Failover | Master-Slave Promotes Replica |
| Conflict Resolution | Required in Master-Master |
| Simplicity | Master-Slave |
| High Availability | Both |
| Production Choice | Usually Master-Slave |
Interview Tips
Interviewers frequently ask
- Explain Master-Slave Replication.
- Explain Master-Master Replication.
- Master-Slave vs Master-Master.
- Which architecture is easier?
- Why are write conflicts possible?
- Which architecture provides write scaling?
- Which architecture is preferred in banking?
- What is split brain?
- How do you resolve write conflicts?
- Which architecture would you recommend for a global SaaS application?
A strong interview explanation is:
"Master-Slave replication uses a single primary server for writes and one or more replicas for read scaling, making it simple, consistent, and suitable for most enterprise systems. Master-Master replication allows multiple nodes to accept writes, improving availability and supporting multi-region deployments, but it introduces challenges such as write conflicts, split-brain scenarios, and conflict resolution. For most production applications, Master-Slave is preferred unless there is a clear requirement for multi-primary writes."
Summary
Master-Slave and Master-Master are two fundamental database replication architectures. Master-Slave offers simplicity, strong consistency, and excellent read scalability, making it the preferred choice for most enterprise workloads. Master-Master enables multiple writable nodes for geographically distributed or highly available systems but requires sophisticated conflict detection and resolution mechanisms.
Understanding the trade-offs between read scaling, write scaling, consistency, availability, failover, and conflict resolution is essential for Backend Developers, Database Engineers, DevOps Engineers, and Solution Architects designing distributed database systems.