Update scale.md

1 files changed, 12 insertions, 0 deletions

diff --git a/ops/scale.md b/ops/scale.md
index 5708c2a..9d9b800 100644
--- a/ops/scale.md
+++ b/ops/scale.md
@@ -43,6 +43,15 @@ Storage utilization is fine, and easily tuned if necessary. The larger problem
 is that borg triggers lots of CPU consumption on the hosts which are being
 backed up. Managable now but a good candidate for future research.
 
+## Web load balancing
+
+We're already designed with load balancing in mind. Balancing HTTP requests
+across any number of web servers ought to be trivial. However, horizontal
+scaling of web appliances is an expensive optimization, and for the most part
+this is being considered with a low number of nodes (i.e. 3) for the purposes of
+availability moreso than scaling. We should look into other scaling options
+before reaching for web load balancing.
+
 # Domain-specific concerns
 
 ## PostgreSQL
@@ -60,6 +69,9 @@ entirely off of the master server and spin up a third standby. The GraphQL
 backends are already transaction-oriented and use a read-only transaction when
 appropriate, so this would be fairly easy.
 
+If we need to scale writes horizontally, sharding should be in the cards. I
+don't expect us to need that for a long time.
+
 Note: right now we have one hot standby but it serves as a failover and off-site
 backup, and is not typically load-bearing. Latency issues to the backup
 datacenter would likely make bringing it into normal service a non-starter.