**Parent Topic**: [[Software/README]] ## The Asymmetry Adding replication slaves scales *reads*, never *writes*. "A read is executed on only one machine, but writes can't [be scaled] because they must be executed on every machine for replication to work." Splitting reads between master and slaves is **read/write splitting**; adding servers this way is **scaling out** (horizontal), versus **scaling up** (vertical) by buying bigger servers. ## Four Diminishing Returns Schwartz names where it stops paying off: - **Read/write ratio** — read-heavy apps scale out near-linearly; write-heavy apps not at all (slaves just duplicate the master's writes). - **Master write load** — as writes grow, the master's write workload squeezes its own read capacity, and the same writes squeeze every slave; effectiveness "drops sharply" near the master's limit. - **Operational cost** — more servers = more failures. "If the mean time between failures is a year, with 12 servers you can expect a failure every month; with 24, every two weeks." Slaves depend on masters; promotion is rarely seamless. - **Application complexity** — going from one to two data sources is a significant shift, even with connection pools and load balancers. ## The Limit Replication eventually hits a wall at the master's write capacity, which is what forces [[Functional Partitioning of Databases]] and ultimately [[Dread Sharding]]. The lag it introduces is [[Async Replication Lag]]. Extends Ch 9's [[Read-Only Replica Cluster]]. --- *Source: [[Web Operations]] (Allspaw & Robbins, O'Reilly 2010) — Ch 12 — Relational Database Strategy and Tactics for the Web*