A Primary-Replica setup (also known as Master-Slave setup) is a database architecture where you have one primary database (the master) that handles write operations, and one or more replica databases (slaves) that handle read operations.

---

Key Components of Primary-Replica Setup:

1. Primary (Master) Database:

   • Handles all write operations (inserts, updates, deletes).
   • Propagates changes (data modifications) to the replica databases.

2. Replica (Slave) Databases:

   • Replicas are copies of the primary database.
   • Read-only — they handle read operations (queries like SELECT).
   • They synchronize with the primary, either in real-time or with a delay, to get updated data.

---

How Does It Work?

1. Write Operations:

   • All writes (INSERT, UPDATE, DELETE) happen on the primary database.

2. Replication:

   • Changes made on the primary are automatically propagated to the replicas using a process called replication.
   • This can be done via synchronous replication (where replicas must confirm the write) or asynchronous replication (where the primary doesn’t wait for replicas to confirm).

3. Read Operations:

   • Read queries (SELECT) are directed to replica databases, which can be used to distribute the load, improving scalability and performance.

4. Data Consistency:

   • In an asynchronous setup, replicas might not immediately reflect the latest changes from the primary (data lag).
   • In a synchronous setup, replicas are kept in sync with the primary at all times, ensuring consistency, but might incur performance overhead.

---

Why Use Primary-Replica Setup?

1. Scalability:

   • Distribute read traffic across replicas to handle more queries without overloading the primary.

2. High Availability:

   • If the primary database goes down, you can promote a replica to become the new primary (failover).

3. Load Balancing:

   • Read requests are offloaded to replicas, reducing the load on the primary.

4. Backup and Reporting:

   • Replicas can be used for backups and reporting without affecting the primary database performance.

---

When to Use Primary-Replica Setup:

• Read-heavy applications where you want to offload read traffic from the primary database.
• High availability scenarios where you want automatic failover if the primary database goes down.
• Data consistency isn’t an immediate concern, and the system can tolerate slight lag in data replication.

---

Limitations of Primary-Replica Setup:

1. Write Bottleneck:

   • Only the primary database can handle writes, which can become a bottleneck if your application generates a lot of write-heavy traffic.

2. Replication Lag:

   • In asynchronous setups, there may be data lag between the primary and replicas. This means replicas might serve slightly outdated data.

3. Complexity:

   • Managing the replication, failover, and promoting replicas to primary can be complex at scale.

---

Example Scenario:

• Primary Database (Master): Handles all user account creation, updates, deletions, etc.
• Replicas (Slaves): Handle user queries, e.g., fetching user details, displaying posts, etc. This way, the primary database can focus on critical updates, while replicas manage read traffic.

---

In short:

A Primary-Replica setup is a way to scale databases, distribute load, and improve performance by having one primary database for writes and one or more replicas for reads.