Ah, David Malan, we meet again. Many months have passed since I waded through your hyper-caffeinated orations in CS50, and now I find you building dynamic websites in the summer of 2012. I accept your challenge.
Begins with a brief recap on what we look for from a web host, including confirming FSTP (vs. FTP) to ensure security and deciding how fast we think we might scale (so we’re not pushed out by other users on a shared system). If we expect to grow, why not consider Virtual Private Services (VPSs), like Amazon’s EC2, where we can self-service and spawn servers as needed.
The distinction is made between vertical scaling (buying more processing, RAM, memory power) vs. horizonal scaling (distributing tasks across a network of servers, which can been smaller and cheaper). For the latter, David explores different approaches the load balancer can take to process client requests.
Random array of independent disks (RAID) is introduced as a possible solution for safely storing session states (with some protection for system failures). RAID0 stripes the data across two drives. RAID1 mirrors the data across two drives. RAID3 and RAID5 only holds one drive out for redundancy, freeing the others to process. RAID6, any two drives can die and you still have all the data backed up.
Some caching approaches are presented, including the .html approach of Craigslist, which prioritizes reads, in that the static, pre-generated and stored pages are quick to load, over writes and design modifications. MySQL has a query_cache that can be enabled in the my.cnf file, which will keep track of queries, and then referenced the cached query if an identical query is requested. Pretty cool. And finally, memcached, which is used by Facebook, stores key-value pairs in RAM, side-stepping the need for table altogether.
Looking at the primary-replica topology (worst name EVER, why has our field not changed this?!), we can set our writes to be processed to our primary (since they will be propogated to all replica), and then direct writes to the replica. But this creates a single point of failure (the primary). This can be avoided by a replication model. This idea is extended to a multilayer network configuration with an active-active pair of load balencers (one reading packets from the outside, and one directing read requests to databases).