Web Scalability for Startup Engineers

By Artur Ejsmont (2015)

My Notes

Typical scalability journey:

• A single server for everything
• Upgrade machine/network (vertical scalability)
• Use a CDN
• Deploy each service on a different machine (web server, DB, etc)
• Other horizontal scalability efforts
• Multiple data centres

💡 Different systems will have different needs (bottlenecks will appear in different places).

Vertical Scalability

Upgrade the infrastructure.

• Add memory (to reduce swapping/virtual memory use)
• Use RAID (optimise for throughput)
• Use SSDs (improves random access performance)
• Upgrade the network
• Upgrade/add processors/cores

Horizontal Scalability

Spread the workload logically.

… let’s think of it as running each component on multiple servers and being able to add more servers whenever necessary.

Horizontal Scalability Strategies

Delegate Work

Use REST, make sure GET requests have no side-effects and are constant over time (not: shopping carts, pages that require authorisation). Caches can affect analytics.

• CDNs
• Browser cache
• Web Storage API

Reduce the Workload

• Server-side cache (memcached, Redis, …)
• Denormalise the DB (if high reads-writes ratio)

Spread the Workload

• Cloning (stateless) services behind a load balancer
• Service partitioning
  • Functional: microservice-style
  • Technical: front-end v back-end v …
• DB cluster
  • Multiple read-only replicas (beware of operations that will not replicate correctly, e.g., RAND())
  • Sharding. Same schemas, different data. Queries across shards in the app layer only. Use e.g., auto_increment_increment to avoid ID clashes
• Multiple data centres using round-robin DNS or GeoDNS

NoSQL

Origins in distributed stores. Because ACID has problems in distributed stores, they sacrifice parts.

Caching

The higher the better (less work arrives at the lower layers).

Where to apply caching? Measure! Rank each page/endpoint by,

Time to serve response × number of requests made

Speed Comparison