loading image
Back to glossary

Master-Slave

Architecture where a primary component (master) controls and coordinates secondary components (slaves) for load distribution.

Updated on January 26, 2026

Master-Slave architecture is a distributed design pattern where a primary node (master) maintains authority and coordinates operations, while secondary nodes (slaves) replicate data and process read queries. This pattern is fundamental in distributed database systems, storage systems, and high-availability architectures, enabling horizontal scalability and fault tolerance.

Fundamentals of Master-Slave Architecture

  • The master handles all write operations and maintains the authoritative system state
  • Slaves replicate master data and process read queries to distribute load
  • Unidirectional synchronization ensures data consistency from master to slaves
  • Failover mechanisms allow a slave to become master when the primary node fails

Benefits of Master-Slave Architecture

  • Read scalability: distribute query load across multiple slave nodes
  • High availability: service continuity even when a slave fails
  • Workload separation: isolate write and read operations for optimized performance
  • Real-time backup: slaves serve as automatically synchronized backup copies
  • Reduced latency: ability to geolocate slaves near users for read operations

Practical Example with PostgreSQL

database-cluster.ts
import { Pool } from 'pg';

// Master-Slave configuration for PostgreSQL
class DatabaseCluster {
  private masterPool: Pool;
  private slavePools: Pool[];
  private currentSlaveIndex: number = 0;

  constructor() {
    // Connection pool to master (writes)
    this.masterPool = new Pool({
      host: 'master-db.example.com',
      port: 5432,
      database: 'production',
      max: 20,
      idleTimeoutMillis: 30000
    });

    // Connection pools to slaves (reads)
    this.slavePools = [
      new Pool({ host: 'slave1-db.example.com', port: 5432, database: 'production', max: 50 }),
      new Pool({ host: 'slave2-db.example.com', port: 5432, database: 'production', max: 50 }),
      new Pool({ host: 'slave3-db.example.com', port: 5432, database: 'production', max: 50 })
    ];
  }

  // Write operations on the master
  async write(query: string, params: any[]): Promise<any> {
    const client = await this.masterPool.connect();
    try {
      return await client.query(query, params);
    } finally {
      client.release();
    }
  }

  // Read operations with load balancing across slaves
  async read(query: string, params: any[]): Promise<any> {
    const slavePool = this.getNextSlave();
    const client = await slavePool.connect();
    try {
      return await client.query(query, params);
    } catch (error) {
      // Fallback to master if slave is unavailable
      console.warn('Slave unavailable, falling back to master');
      return this.write(query, params);
    } finally {
      client.release();
    }
  }

  // Round-robin load balancing among slaves
  private getNextSlave(): Pool {
    const slave = this.slavePools[this.currentSlaveIndex];
    this.currentSlaveIndex = (this.currentSlaveIndex + 1) % this.slavePools.length;
    return slave;
  }

  // Usage example
  async createUser(email: string, name: string): Promise<void> {
    await this.write(
      'INSERT INTO users (email, name, created_at) VALUES ($1, $2, NOW())',
      [email, name]
    );
  }

  async getUsers(limit: number): Promise<any[]> {
    const result = await this.read(
      'SELECT id, email, name FROM users ORDER BY created_at DESC LIMIT $1',
      [limit]
    );
    return result.rows;
  }
}

// Cluster usage
const db = new DatabaseCluster();

// Write to master
await db.createUser('user@example.com', 'John Doe');

// Distributed read across slaves
const users = await db.getUsers(100);

Implementing Master-Slave Architecture

  1. Identify scalability needs and the read/write ratio of your application
  2. Configure replication from master to slaves (streaming replication, log shipping)
  3. Implement a routing mechanism to direct writes to master and reads to slaves
  4. Set up monitoring systems to track replication lag
  5. Configure automatic failover mechanisms (slave promotion) with tools like Patroni or Keepalived
  6. Regularly test failover scenarios and validate recovery time objectives (RTO/RPO)
  7. Document topology and intervention procedures for failure scenarios

Pro tip

Monitor replication lag between master and slaves carefully. Significant lag can lead to stale data reads. Implement read-after-write consistency strategies by temporarily directing sensitive reads to the master after critical writes.

Tools and Associated Technologies

  • PostgreSQL Streaming Replication: native real-time replication
  • MySQL Group Replication: multi-master replication with consensus
  • Redis Sentinel: automatic failover management for Redis
  • Patroni: high availability and automatic failover for PostgreSQL
  • ProxySQL: intelligent proxy for MySQL master/slave routing
  • HAProxy: load balancer for connection distribution
  • Pgpool-II: pooling and replication middleware for PostgreSQL

Inclusive Terminology

The tech industry is evolving toward more inclusive terminology. Alternative terms like Primary-Replica, Leader-Follower, or Primary-Secondary are increasingly favored in new documentation and implementations while maintaining the same technical architecture.

Master-Slave architecture remains a fundamental pattern for building performant and resilient distributed systems. By intelligently separating read and write workloads, it enables the scalability and availability levels essential for modern high-traffic applications. Its rigorous implementation, combined with proactive monitoring and robust failover mechanisms, ensures an infrastructure capable of supporting growth while maintaining data integrity.

Themoneyisalreadyonthetable.

In 1 hour, discover exactly how much you're losing and how to recover it.

Web development, automation & AI agency

contact@peaklab.fr
Newsletter

Get our tech and business tips delivered straight to your inbox.

Follow us

© PeakLab 2025