diff --git a/solutions/system_design/mint/README.md b/solutions/system_design/mint/README.md
index 1ec31674db0..a6b0bd70233 100644
--- a/solutions/system_design/mint/README.md
+++ b/solutions/system_design/mint/README.md
@@ -333,7 +333,7 @@ class SpendingByCategory(MRJob):
State you would 1) **Benchmark/Load Test**, 2) **Profile** for bottlenecks 3) address bottlenecks while evaluating alternatives and trade-offs, and 4) repeat. See [Design a system that scales to millions of users on AWS](../scaling_aws/README.md) as a sample on how to iteratively scale the initial design.
-It's important to discuss what bottlenecks you might encounter with the initial design and how you might address each of them. For example, what issues are addressed by adding a **Load Balancer** with multiple **Web Servers**? **CDN**? **Master-Slave Replicas**? What are the alternatives and **Trade-Offs** for each?
+It's important to discuss what bottlenecks you might encounter with the initial design and how you might address each of them. For example, what issues are addressed by adding a **Load Balancer** with multiple **Web Servers**? **CDN**? **Primary-Replica Replicas**? What are the alternatives and **Trade-Offs** for each?
We'll introduce some components to complete the design and to address scalability issues. Internal load balancers are not shown to reduce clutter.
@@ -347,8 +347,8 @@ We'll introduce some components to complete the design and to address scalabilit
* [API server (application layer)](https://github.com/donnemartin/system-design-primer#application-layer)
* [Cache](https://github.com/donnemartin/system-design-primer#cache)
* [Relational database management system (RDBMS)](https://github.com/donnemartin/system-design-primer#relational-database-management-system-rdbms)
-* [SQL write master-slave failover](https://github.com/donnemartin/system-design-primer#fail-over)
-* [Master-slave replication](https://github.com/donnemartin/system-design-primer#master-slave-replication)
+* [SQL write primary-replica failover](https://github.com/donnemartin/system-design-primer#fail-over)
+* [Primary-replica replication](https://github.com/donnemartin/system-design-primer#primary-replica-replication)
* [Asynchronism](https://github.com/donnemartin/system-design-primer#asynchronism)
* [Consistency patterns](https://github.com/donnemartin/system-design-primer#consistency-patterns)
* [Availability patterns](https://github.com/donnemartin/system-design-primer#availability-patterns)
@@ -375,7 +375,7 @@ We might only want to store a month of `transactions` data in the database, whil
To address the 200 *average* read requests per second (higher at peak), traffic for popular content should be handled by the **Memory Cache** instead of the database. The **Memory Cache** is also useful for handling the unevenly distributed traffic and traffic spikes. The **SQL Read Replicas** should be able to handle the cache misses, as long as the replicas are not bogged down with replicating writes.
-2,000 *average* transaction writes per second (higher at peak) might be tough for a single **SQL Write Master-Slave**. We might need to employ additional SQL scaling patterns:
+2,000 *average* transaction writes per second (higher at peak) might be tough for a single **SQL Write Primary-Replica**. We might need to employ additional SQL scaling patterns:
* [Federation](https://github.com/donnemartin/system-design-primer#federation)
* [Sharding](https://github.com/donnemartin/system-design-primer#sharding)
diff --git a/solutions/system_design/pastebin/README-zh-Hans.md b/solutions/system_design/pastebin/README-zh-Hans.md
index d2946e97090..dc2aabb4dce 100644
--- a/solutions/system_design/pastebin/README-zh-Hans.md
+++ b/solutions/system_design/pastebin/README-zh-Hans.md
@@ -239,7 +239,7 @@ class HitCounts(MRJob):
说明您将迭代地执行这样的操作：1)**Benchmark/Load 测试**，2)**Profile** 出瓶颈，3)在评估替代方案和权衡时解决瓶颈，4)重复前面，可以参考[在 AWS 上设计一个可以支持百万用户的系统](../scaling_aws/README.md)这个用来解决如何迭代地扩展初始设计的例子。
-重要的是讨论在初始设计中可能遇到的瓶颈，以及如何解决每个瓶颈。比如，在多个 **Web 服务器** 上添加 **负载平衡器** 可以解决哪些问题？ **CDN** 解决哪些问题？**Master-Slave Replicas** 解决哪些问题? 替代方案是什么和怎么对每一个替代方案进行权衡比较？
+重要的是讨论在初始设计中可能遇到的瓶颈，以及如何解决每个瓶颈。比如，在多个 **Web 服务器** 上添加 **负载平衡器** 可以解决哪些问题？ **CDN** 解决哪些问题？**Primary-Replica Replicas** 解决哪些问题? 替代方案是什么和怎么对每一个替代方案进行权衡比较？
我们将介绍一些组件来完成设计，并解决可伸缩性问题。内部的负载平衡器并不能减少杂乱。
@@ -253,7 +253,7 @@ class HitCounts(MRJob):
* [应用层](https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md#应用层)
* [缓存](https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md#缓存)
* [关系型数据库管理系统 (RDBMS)](https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md#关系型数据库管理系统rdbms)
-* [SQL write master-slave failover](https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md#故障切换)
+* [SQL write primary-replica failover](https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md#故障切换)
* [主从复制](https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md#主从复制)
* [一致性模式](https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md#一致性模式)
* [可用性模式](https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md#可用性模式)
@@ -264,7 +264,7 @@ class HitCounts(MRJob):
要处理 *平均* 每秒 40 读请求(峰值更高)，其中热点内容的流量应该由 **内存缓存** 处理，而不是数据库。**内存缓存** 对于处理分布不均匀的流量和流量峰值也很有用。只要副本没有陷入复制写的泥潭，**SQL Read Replicas** 应该能够处理缓存丢失。
-对于单个 **SQL Write Master-Slave**，*平均* 每秒 4paste 写入 (峰值更高) 应该是可以做到的。否则，我们需要使用额外的 SQL 扩展模式:
+对于单个 **SQL Write Primary-Replica**，*平均* 每秒 4paste 写入 (峰值更高) 应该是可以做到的。否则，我们需要使用额外的 SQL 扩展模式:
* [联合](https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md#联合)
* [分片](https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md#分片)
diff --git a/solutions/system_design/pastebin/README.md b/solutions/system_design/pastebin/README.md
index 2d87ddcc7e3..5b9d971ebdd 100644
--- a/solutions/system_design/pastebin/README.md
+++ b/solutions/system_design/pastebin/README.md
@@ -241,7 +241,7 @@ To delete expired pastes, we could just scan the **SQL Database** for all entrie
State you would do this iteratively: 1) **Benchmark/Load Test**, 2) **Profile** for bottlenecks 3) address bottlenecks while evaluating alternatives and trade-offs, and 4) repeat. See [Design a system that scales to millions of users on AWS](../scaling_aws/README.md) as a sample on how to iteratively scale the initial design.
-It's important to discuss what bottlenecks you might encounter with the initial design and how you might address each of them. For example, what issues are addressed by adding a **Load Balancer** with multiple **Web Servers**? **CDN**? **Master-Slave Replicas**? What are the alternatives and **Trade-Offs** for each?
+It's important to discuss what bottlenecks you might encounter with the initial design and how you might address each of them. For example, what issues are addressed by adding a **Load Balancer** with multiple **Web Servers**? **CDN**? **Primary-Replica Replicas**? What are the alternatives and **Trade-Offs** for each?
We'll introduce some components to complete the design and to address scalability issues. Internal load balancers are not shown to reduce clutter.
@@ -255,8 +255,8 @@ We'll introduce some components to complete the design and to address scalabilit
* [API server (application layer)](https://github.com/donnemartin/system-design-primer#application-layer)
* [Cache](https://github.com/donnemartin/system-design-primer#cache)
* [Relational database management system (RDBMS)](https://github.com/donnemartin/system-design-primer#relational-database-management-system-rdbms)
-* [SQL write master-slave failover](https://github.com/donnemartin/system-design-primer#fail-over)
-* [Master-slave replication](https://github.com/donnemartin/system-design-primer#master-slave-replication)
+* [SQL write primary-replica failover](https://github.com/donnemartin/system-design-primer#fail-over)
+* [Primary-replica replication](https://github.com/donnemartin/system-design-primer#primary-replica-replication)
* [Consistency patterns](https://github.com/donnemartin/system-design-primer#consistency-patterns)
* [Availability patterns](https://github.com/donnemartin/system-design-primer#availability-patterns)
@@ -266,7 +266,7 @@ An **Object Store** such as Amazon S3 can comfortably handle the constraint of 1
To address the 40 *average* read requests per second (higher at peak), traffic for popular content should be handled by the **Memory Cache** instead of the database. The **Memory Cache** is also useful for handling the unevenly distributed traffic and traffic spikes. The **SQL Read Replicas** should be able to handle the cache misses, as long as the replicas are not bogged down with replicating writes.
-4 *average* paste writes per second (with higher at peak) should be do-able for a single **SQL Write Master-Slave**. Otherwise, we'll need to employ additional SQL scaling patterns:
+4 *average* paste writes per second (with higher at peak) should be do-able for a single **SQL Write Primary-Replica**. Otherwise, we'll need to employ additional SQL scaling patterns:
* [Federation](https://github.com/donnemartin/system-design-primer#federation)
* [Sharding](https://github.com/donnemartin/system-design-primer#sharding)
diff --git a/solutions/system_design/query_cache/README.md b/solutions/system_design/query_cache/README.md
index 032adf34abd..1de70bd0053 100644
--- a/solutions/system_design/query_cache/README.md
+++ b/solutions/system_design/query_cache/README.md
@@ -218,7 +218,7 @@ Refer to [When to update the cache](https://github.com/donnemartin/system-design
State you would 1) **Benchmark/Load Test**, 2) **Profile** for bottlenecks 3) address bottlenecks while evaluating alternatives and trade-offs, and 4) repeat. See [Design a system that scales to millions of users on AWS](../scaling_aws/README.md) as a sample on how to iteratively scale the initial design.
-It's important to discuss what bottlenecks you might encounter with the initial design and how you might address each of them. For example, what issues are addressed by adding a **Load Balancer** with multiple **Web Servers**? **CDN**? **Master-Slave Replicas**? What are the alternatives and **Trade-Offs** for each?
+It's important to discuss what bottlenecks you might encounter with the initial design and how you might address each of them. For example, what issues are addressed by adding a **Load Balancer** with multiple **Web Servers**? **CDN**? **Primary-Replica Replicas**? What are the alternatives and **Trade-Offs** for each?
We'll introduce some components to complete the design and to address scalability issues. Internal load balancers are not shown to reduce clutter.
@@ -247,7 +247,7 @@ To handle the heavy request load and the large amount of memory needed, we'll sc
### SQL scaling patterns
-* [Read replicas](https://github.com/donnemartin/system-design-primer#master-slave-replication)
+* [Read replicas](https://github.com/donnemartin/system-design-primer#primary-replica-replication)
* [Federation](https://github.com/donnemartin/system-design-primer#federation)
* [Sharding](https://github.com/donnemartin/system-design-primer#sharding)
* [Denormalization](https://github.com/donnemartin/system-design-primer#denormalization)
diff --git a/solutions/system_design/sales_rank/README.md b/solutions/system_design/sales_rank/README.md
index 71ad1c7d202..b7e75718900 100644
--- a/solutions/system_design/sales_rank/README.md
+++ b/solutions/system_design/sales_rank/README.md
@@ -245,7 +245,7 @@ For internal communications, we could use [Remote Procedure Calls](https://githu
State you would 1) **Benchmark/Load Test**, 2) **Profile** for bottlenecks 3) address bottlenecks while evaluating alternatives and trade-offs, and 4) repeat. See [Design a system that scales to millions of users on AWS](../scaling_aws/README.md) as a sample on how to iteratively scale the initial design.
-It's important to discuss what bottlenecks you might encounter with the initial design and how you might address each of them. For example, what issues are addressed by adding a **Load Balancer** with multiple **Web Servers**? **CDN**? **Master-Slave Replicas**? What are the alternatives and **Trade-Offs** for each?
+It's important to discuss what bottlenecks you might encounter with the initial design and how you might address each of them. For example, what issues are addressed by adding a **Load Balancer** with multiple **Web Servers**? **CDN**? **Primary-Replica Replicas**? What are the alternatives and **Trade-Offs** for each?
We'll introduce some components to complete the design and to address scalability issues. Internal load balancers are not shown to reduce clutter.
@@ -259,8 +259,8 @@ We'll introduce some components to complete the design and to address scalabilit
* [API server (application layer)](https://github.com/donnemartin/system-design-primer#application-layer)
* [Cache](https://github.com/donnemartin/system-design-primer#cache)
* [Relational database management system (RDBMS)](https://github.com/donnemartin/system-design-primer#relational-database-management-system-rdbms)
-* [SQL write master-slave failover](https://github.com/donnemartin/system-design-primer#fail-over)
-* [Master-slave replication](https://github.com/donnemartin/system-design-primer#master-slave-replication)
+* [SQL write primary-replica failover](https://github.com/donnemartin/system-design-primer#fail-over)
+* [Primary-replica replication](https://github.com/donnemartin/system-design-primer#primary-replica-replication)
* [Consistency patterns](https://github.com/donnemartin/system-design-primer#consistency-patterns)
* [Availability patterns](https://github.com/donnemartin/system-design-primer#availability-patterns)
@@ -270,7 +270,7 @@ We might only want to store a limited time period of data in the database, while
To address the 40,000 *average* read requests per second (higher at peak), traffic for popular content (and their sales rank) should be handled by the **Memory Cache** instead of the database. The **Memory Cache** is also useful for handling the unevenly distributed traffic and traffic spikes. With the large volume of reads, the **SQL Read Replicas** might not be able to handle the cache misses. We'll probably need to employ additional SQL scaling patterns.
-400 *average* writes per second (higher at peak) might be tough for a single **SQL Write Master-Slave**, also pointing to a need for additional scaling techniques.
+400 *average* writes per second (higher at peak) might be tough for a single **SQL Write Primary-Replica**, also pointing to a need for additional scaling techniques.
SQL scaling patterns include:
diff --git a/solutions/system_design/scaling_aws/README-zh-Hans.md b/solutions/system_design/scaling_aws/README-zh-Hans.md
index c071c70eb08..aa63cce3a56 100644
--- a/solutions/system_design/scaling_aws/README-zh-Hans.md
+++ b/solutions/system_design/scaling_aws/README-zh-Hans.md
@@ -207,7 +207,7 @@
* 如果你正在配置自己的 **负载均衡器**, 在多个可用区域中设置多台服务器用于 [双活](https://github.com/donnemartin/system-design-primer#active-active) 或 [主被](https://github.com/donnemartin/system-design-primer#active-passive) 将提高可用性
* 终止在 **负载平衡器** 上的SSL，以减少后端服务器上的计算负载，并简化证书管理
* 在多个可用区域中使用多台 **Web服务器**
- * 在多个可用区域的 [**主-从 故障转移**](https://github.com/donnemartin/system-design-primer#master-slave-replication) 模式中使用多个 **MySQL** 实例来改进冗余
+ * 在多个可用区域的 [**主-从 故障转移**](https://github.com/donnemartin/system-design-primer#primary-replica-replication) 模式中使用多个 **MySQL** 实例来改进冗余
* 分离 **Web 服务器** 和 [**应用服务器**](https://github.com/donnemartin/system-design-primer#application-layer)
* 独立扩展和配置每一层
* **Web 服务器** 可以作为 [**反向代理**](https://github.com/donnemartin/system-design-primer#reverse-proxy-web-server)
@@ -238,7 +238,7 @@
* 来自 **Web 服务器** 的会话数据
* **Web 服务器** 变成无状态的, 允许 **自动伸缩**
* 从内存中读取 1 MB 内存需要大约 250 微秒，而从SSD中读取时间要长 4 倍，从磁盘读取的时间要长 80 倍。1
-* 添加 [**MySQL 读取副本**](https://github.com/donnemartin/system-design-primer#master-slave-replication) 来减少写主线程的负载
+* 添加 [**MySQL 读取副本**](https://github.com/donnemartin/system-design-primer#primary-replica-replication) 来减少写主线程的负载
* 添加更多 **Web 服务器** and **应用服务器** 来提高响应
**折中方案, 可选方案, 和其他细节:**
@@ -344,7 +344,7 @@ SQL 扩展模型包括：
### SQL 扩展模式
-* [读取副本](https://github.com/donnemartin/system-design-primer#master-slave-replication)
+* [读取副本](https://github.com/donnemartin/system-design-primer#primary-replica-replication)
* [集合](https://github.com/donnemartin/system-design-primer#federation)
* [分区](https://github.com/donnemartin/system-design-primer#sharding)
* [反规范化](https://github.com/donnemartin/system-design-primer#denormalization)
diff --git a/solutions/system_design/scaling_aws/README.md b/solutions/system_design/scaling_aws/README.md
index 99af0cfff8d..a3a3f7e4d04 100644
--- a/solutions/system_design/scaling_aws/README.md
+++ b/solutions/system_design/scaling_aws/README.md
@@ -207,7 +207,7 @@ Our **Benchmarks/Load Tests** and **Profiling** show that our single **Web Serve
* If you are configuring your own **Load Balancer**, setting up multiple servers in [active-active](https://github.com/donnemartin/system-design-primer#active-active) or [active-passive](https://github.com/donnemartin/system-design-primer#active-passive) in multiple availability zones will improve availability
* Terminate SSL on the **Load Balancer** to reduce computational load on backend servers and to simplify certificate administration
* Use multiple **Web Servers** spread out over multiple availability zones
- * Use multiple **MySQL** instances in [**Master-Slave Failover**](https://github.com/donnemartin/system-design-primer#master-slave-replication) mode across multiple availability zones to improve redundancy
+ * Use multiple **MySQL** instances in [**Primary-Replica Failover**](https://github.com/donnemartin/system-design-primer#primary-replica-replication) mode across multiple availability zones to improve redundancy
* Separate out the **Web Servers** from the [**Application Servers**](https://github.com/donnemartin/system-design-primer#application-layer)
* Scale and configure both layers independently
* **Web Servers** can run as a [**Reverse Proxy**](https://github.com/donnemartin/system-design-primer#reverse-proxy-web-server)
@@ -238,7 +238,7 @@ Our **Benchmarks/Load Tests** and **Profiling** show that we are read-heavy (100
* Session data from the **Web Servers**
* The **Web Servers** become stateless, allowing for **Autoscaling**
* Reading 1 MB sequentially from memory takes about 250 microseconds, while reading from SSD takes 4x and from disk takes 80x longer.1
-* Add [**MySQL Read Replicas**](https://github.com/donnemartin/system-design-primer#master-slave-replication) to reduce load on the write master
+* Add [**MySQL Read Replicas**](https://github.com/donnemartin/system-design-primer#primary-replica-replication) to reduce load on the write master
* Add more **Web Servers** and **Application Servers** to improve responsiveness
*Trade-offs, alternatives, and additional details:*
@@ -313,7 +313,7 @@ We'll continue to address scaling issues due to the problem's constraints:
* A data warehouse such as Redshift can comfortably handle the constraint of 1 TB of new content per month
* With 40,000 average read requests per second, read traffic for popular content can be addressed by scaling the **Memory Cache**, which is also useful for handling the unevenly distributed traffic and traffic spikes
* The **SQL Read Replicas** might have trouble handling the cache misses, we'll probably need to employ additional SQL scaling patterns
-* 400 average writes per second (with presumably significantly higher peaks) might be tough for a single **SQL Write Master-Slave**, also pointing to a need for additional scaling techniques
+* 400 average writes per second (with presumably significantly higher peaks) might be tough for a single **SQL Write Primary-Replica**, also pointing to a need for additional scaling techniques
SQL scaling patterns include:
@@ -344,7 +344,7 @@ We can further separate out our [**Application Servers**](https://github.com/don
### SQL scaling patterns
-* [Read replicas](https://github.com/donnemartin/system-design-primer#master-slave-replication)
+* [Read replicas](https://github.com/donnemartin/system-design-primer#primary-replica-replication)
* [Federation](https://github.com/donnemartin/system-design-primer#federation)
* [Sharding](https://github.com/donnemartin/system-design-primer#sharding)
* [Denormalization](https://github.com/donnemartin/system-design-primer#denormalization)
diff --git a/solutions/system_design/social_graph/README-zh-Hans.md b/solutions/system_design/social_graph/README-zh-Hans.md
index 07b8e3e7886..a4e5a1609be 100644
--- a/solutions/system_design/social_graph/README-zh-Hans.md
+++ b/solutions/system_design/social_graph/README-zh-Hans.md
@@ -289,7 +289,7 @@ $ curl https://social.com/api/v1/friend_search?person_id=1234
### SQL 扩展模式
-* [读取副本](https://github.com/donnemartin/system-design-primer#master-slave-replication)
+* [读取副本](https://github.com/donnemartin/system-design-primer#primary-replica-replication)
* [集合](https://github.com/donnemartin/system-design-primer#federation)
* [分区](https://github.com/donnemartin/system-design-primer#sharding)
* [反规范化](https://github.com/donnemartin/system-design-primer#denormalization)
diff --git a/solutions/system_design/social_graph/README.md b/solutions/system_design/social_graph/README.md
index f7dfd4efe8d..2ca31bd3d7c 100644
--- a/solutions/system_design/social_graph/README.md
+++ b/solutions/system_design/social_graph/README.md
@@ -256,7 +256,7 @@ For internal communications, we could use [Remote Procedure Calls](https://githu
State you would 1) **Benchmark/Load Test**, 2) **Profile** for bottlenecks 3) address bottlenecks while evaluating alternatives and trade-offs, and 4) repeat. See [Design a system that scales to millions of users on AWS](../scaling_aws/README.md) as a sample on how to iteratively scale the initial design.
-It's important to discuss what bottlenecks you might encounter with the initial design and how you might address each of them. For example, what issues are addressed by adding a **Load Balancer** with multiple **Web Servers**? **CDN**? **Master-Slave Replicas**? What are the alternatives and **Trade-Offs** for each?
+It's important to discuss what bottlenecks you might encounter with the initial design and how you might address each of them. For example, what issues are addressed by adding a **Load Balancer** with multiple **Web Servers**? **CDN**? **Primary-Replica Replicas**? What are the alternatives and **Trade-Offs** for each?
We'll introduce some components to complete the design and to address scalability issues. Internal load balancers are not shown to reduce clutter.
@@ -290,7 +290,7 @@ Below are further optimizations:
### SQL scaling patterns
-* [Read replicas](https://github.com/donnemartin/system-design-primer#master-slave-replication)
+* [Read replicas](https://github.com/donnemartin/system-design-primer#primary-replica-replication)
* [Federation](https://github.com/donnemartin/system-design-primer#federation)
* [Sharding](https://github.com/donnemartin/system-design-primer#sharding)
* [Denormalization](https://github.com/donnemartin/system-design-primer#denormalization)
diff --git a/solutions/system_design/twitter/README.md b/solutions/system_design/twitter/README.md
index d14996f1526..de7a2e2bd35 100644
--- a/solutions/system_design/twitter/README.md
+++ b/solutions/system_design/twitter/README.md
@@ -229,7 +229,7 @@ The response would be similar to that of the home timeline, except for tweets ma
State you would 1) **Benchmark/Load Test**, 2) **Profile** for bottlenecks 3) address bottlenecks while evaluating alternatives and trade-offs, and 4) repeat. See [Design a system that scales to millions of users on AWS](../scaling_aws/README.md) as a sample on how to iteratively scale the initial design.
-It's important to discuss what bottlenecks you might encounter with the initial design and how you might address each of them. For example, what issues are addressed by adding a **Load Balancer** with multiple **Web Servers**? **CDN**? **Master-Slave Replicas**? What are the alternatives and **Trade-Offs** for each?
+It's important to discuss what bottlenecks you might encounter with the initial design and how you might address each of them. For example, what issues are addressed by adding a **Load Balancer** with multiple **Web Servers**? **CDN**? **Primary-Replica Replicas**? What are the alternatives and **Trade-Offs** for each?
We'll introduce some components to complete the design and to address scalability issues. Internal load balancers are not shown to reduce clutter.
@@ -243,8 +243,8 @@ We'll introduce some components to complete the design and to address scalabilit
* [API server (application layer)](https://github.com/donnemartin/system-design-primer#application-layer)
* [Cache](https://github.com/donnemartin/system-design-primer#cache)
* [Relational database management system (RDBMS)](https://github.com/donnemartin/system-design-primer#relational-database-management-system-rdbms)
-* [SQL write master-slave failover](https://github.com/donnemartin/system-design-primer#fail-over)
-* [Master-slave replication](https://github.com/donnemartin/system-design-primer#master-slave-replication)
+* [SQL write primary-replica failover](https://github.com/donnemartin/system-design-primer#fail-over)
+* [Primary-replica replication](https://github.com/donnemartin/system-design-primer#primary-replica-replication)
* [Consistency patterns](https://github.com/donnemartin/system-design-primer#consistency-patterns)
* [Availability patterns](https://github.com/donnemartin/system-design-primer#availability-patterns)
@@ -267,7 +267,7 @@ We'll also want to address the bottleneck with the **SQL Database**.
Although the **Memory Cache** should reduce the load on the database, it is unlikely the **SQL Read Replicas** alone would be enough to handle the cache misses. We'll probably need to employ additional SQL scaling patterns.
-The high volume of writes would overwhelm a single **SQL Write Master-Slave**, also pointing to a need for additional scaling techniques.
+The high volume of writes would overwhelm a single **SQL Write Primary-Replica**, also pointing to a need for additional scaling techniques.
* [Federation](https://github.com/donnemartin/system-design-primer#federation)
* [Sharding](https://github.com/donnemartin/system-design-primer#sharding)
diff --git a/solutions/system_design/web_crawler/README.md b/solutions/system_design/web_crawler/README.md
index e6e79ad2245..61fe3a82d55 100644
--- a/solutions/system_design/web_crawler/README.md
+++ b/solutions/system_design/web_crawler/README.md
@@ -262,7 +262,7 @@ For internal communications, we could use [Remote Procedure Calls](https://githu
State you would 1) **Benchmark/Load Test**, 2) **Profile** for bottlenecks 3) address bottlenecks while evaluating alternatives and trade-offs, and 4) repeat. See [Design a system that scales to millions of users on AWS](../scaling_aws/README.md) as a sample on how to iteratively scale the initial design.
-It's important to discuss what bottlenecks you might encounter with the initial design and how you might address each of them. For example, what issues are addressed by adding a **Load Balancer** with multiple **Web Servers**? **CDN**? **Master-Slave Replicas**? What are the alternatives and **Trade-Offs** for each?
+It's important to discuss what bottlenecks you might encounter with the initial design and how you might address each of them. For example, what issues are addressed by adding a **Load Balancer** with multiple **Web Servers**? **CDN**? **Primary-Replica Replicas**? What are the alternatives and **Trade-Offs** for each?
We'll introduce some components to complete the design and to address scalability issues. Internal load balancers are not shown to reduce clutter.
@@ -294,7 +294,7 @@ Below are a few other optimizations to the **Crawling Service**:
### SQL scaling patterns
-* [Read replicas](https://github.com/donnemartin/system-design-primer#master-slave-replication)
+* [Read replicas](https://github.com/donnemartin/system-design-primer#primary-replica-replication)
* [Federation](https://github.com/donnemartin/system-design-primer#federation)
* [Sharding](https://github.com/donnemartin/system-design-primer#sharding)
* [Denormalization](https://github.com/donnemartin/system-design-primer#denormalization)