Replication

Creating primary and read-only copies of a database to spread out the load and improve availability

Overview

Database replication creates copies of your database across multiple servers. A primary (master) server handles writes, and replica (slave) servers handle reads.

This improves read performance, provides redundancy for disaster recovery, and enables geographic distribution.

Key Concepts

Primary (Master)

The main database server that handles all write operations. Source of truth for data.

Replica (Slave)

Copy of the primary database. Handles read operations. Data is synchronized from primary.

Synchronous Replication

Primary waits for replica to confirm write before responding. Slower but guaranteed consistency.

Asynchronous Replication

Primary responds immediately, replica updates later. Faster but potential data lag (replication lag).

How It Works

Setup: Primary DB (writes) → Replica 1 (reads) → Replica 2 (reads) → Replica 3 (reads)

Write Flow:

  1. Application sends INSERT/UPDATE to primary
  2. Primary executes write
  3. Primary sends changes to replicas (replication log)
  4. Replicas apply changes

Read Flow:

  1. Application sends SELECT query
  2. Load balancer routes to available replica
  3. Replica returns data

Replication Lag:

  • Time between primary write and replica update
  • Typically <1 second
  • Can increase under heavy load

Use Cases

Read-heavy applications (social media, e-commerce)

Geographic distribution (replicas in different regions)

Disaster recovery (failover to replica if primary fails)

Analytics (run expensive queries on replica without affecting primary)

Backup without downtime

Best Practices

Use asynchronous replication for performance (most common)

Monitor replication lag

Implement retry logic for replication failures

Use read replicas for analytics and reporting

Send critical reads to primary if strict consistency needed

Implement automatic failover for high availability

Use connection pooling separately for primary and replicas

Consider multi-primary replication for write scaling (more complex)

Interview Tips

What Interviewers Look For

  • Explain primary-replica architecture

  • Discuss async vs sync replication trade-offs

  • Mention replication lag and read-after-write consistency issues

  • Talk about failover strategies when primary goes down

  • Explain how replication helps with read scaling but not write scaling

  • Discuss multi-primary replication for write scaling (complex, conflict resolution needed)

  • Mention specific solutions: MySQL replication, PostgreSQL streaming replication, MongoDB replica sets

AI Tutor

Ask about the topic

Sign in Required

Please sign in to use the AI tutor

Sign In
Replication - Module 5: Scaling the Database | System Design | Revise Algo