Following on from my previous post, the second session I attended was all about scaling.
Scaling systems - Architectures that grow
Kendall Miller presented a very good session with a clear message: "There are three things which will help you scale and one thing that will not - Just remember ACD/C".
Help you to scale:
A - Async
C - Caching
D - Distribution
Inhibits scaling:
C - Consistency
Async:
"Only do what you really need to do now and do everything else later - Determine the critical path for your application". The example Kendall used was Amazon. When you place an order, Amazon's critical path is to capture your order, place it in a queue for processing and send you a confirmation email. Other tasks such as checking stock levels or ensuring the order prints out in the warehouse are ignored at this time as they can all be done later. For the transaction of a user placing an order, only the minimum should be done and feedback given so they are happy that their order has been placed successfully.
Caching:
"Don't do anything you don't have to". Kendall used an example of displaying a customers first name when logging in to a applications homepage. The users name is not going to change very often (if ever) so why go to the database each time to retrieve it when the homepage is loaded? Cache it! Even if the user did change their name and it took a short while to update, they probably would not mind or even notice. Caching should be your first option when attempting to improve performance.
Distribution:
"Get as many people to do the work as possible". This is focused on adding additional resources to your application (multiple web-servers, databases etc) so your application can scale out. He highlighted some of the common challenges with this and introduced the idea of partitioning - Partitioning data / a whole system which has a common factor. Using Amazon, Kendell illustrated a high level example of partitioning is Amazon.com and Amazon.co.uk - Users are partitioned based on their geographical location. This allows Amazon to be comprised of multiple sub systems instead of one massive system.
Consistency:
"The degree to which all parties observe the same state of the system at the same time". Kendell put across a valid point that we tend to put stricter than required consistency requirements on our systems. The example used here was the order number. Say a system was being developed with distribution in mind to allow multiple orders to be processed simultaneously, however, when talking to the accounts people they have specified that order numbers must be sequential, we have a potential problem. As the order numbers must be sequential we can only now have one system which generates order numbers for orders to be processed providing a bottle neck to our multiple order processors who are left waiting for order numbers. The question to ask here is: "Do you really need sequential order numbers?"
I walked away from this session very happy as it had fulfilled my expectations of learning some very high level techniques and architectures for allowing systems to scale.
You can find the slides to Kendell's session here.
