mirrors/system-design-primer
1
0
Fork 0
mirror of https://github.com/donnemartin/system-design-primer.git synced 2025-12-17 10:28:57 +03:00
Code Issues Projects Releases Wiki Activity

Replace master/slave with primary/replica

Browse Source 
After further feedback I've not updated the images and just made
alterations to the READMEs for mentions of master-slave to
primary-replica
This commit is contained in:
Christopher Mills
2018-09-22 06:59:59 +01:00
parent 53c0cf7de8
commit 399b2bd581
11 changed files with 33 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
solutions/system_design/sales_rank/README.md
View File

@@ -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: