My Ramblings

This was a decent book with some real concrete rules for building scalable architectures.  I really enjoyed reading it because it wasn't full of a lot of cruft but rather it got right to the point.  Each rule was clearly identified and explained which makes it quick and easy to review when the time comes.

Below are a list of my favorite rules from the book.

• Resist the urge to overengineer solutions by testingease of understanding with fellow engineers.
• Teams can save a lot of money and time by thinking of how to scale solutions early, implementing (coding)them a month or so before they are needed,and implementing them days before the customer rush or demand.
• Minimize the number of DNS lookups required to download pages,but balance this with the browsers limitation forsimultaneous connections.
• Reduce or combine objects but balance this with maximizing simultaneous connections.
• Dont get caught in the trap of expecting to scale up only to find out that youve run out of faster and larger systemsto purchase.
• When implementing disaster recovery, lower your cost of disaster recovery by designing your systems to leveragethree or more live data centers. Use the spare capacity for spiky demand when necessary.
• Design to leverage virtualization and the cloud to meet unexpected spiky demand.
• While firewalls are useful,they are often over-used and represent both an availability and scalability concern if not designed and implemented properly.
• Use the right storage tool for your data. Don't get lured into sticking everything in a relational database just because you are comfortable accessing data in a database.
• Never read what you just wrote for the purpose of validation. Store data in a local or distributed cache if it is required for operations in the near future.
• Redirects in general delay the user,consume computation resources,and are prone to errors.
• CDNs are a fast and simple way to offset spikiness of traffic as well as traffic growth in general. Make sure youperform a cost-benefit analysis and monitor the CDN usage.
• Use Expires headers to reduce requests and improve the scalability and performance of your system.
• Leverage Ajax and cache Ajax calls as much as possible to increase user satisfaction and increase scalability.
• Page caches are a great way to offload dynamic requests and to scale cost effectively.
• Application caching provides the ability to scale cost effectively,but should be complmentary to the architecture of the sys-tem.
• A fairly straightforward object cache implementation can save a lot of computational resources on application servers ordatabase servers.
• Watch your customers or use A/B testing to deter-mine what works. Use postmortems to learn from incidents and problems in production.
• Ensure all releases have the ability to roll back,practice it in a staging or QA environment,and use it in production when necessary to resolve customer incidents.
• Never let a good failure go to waste. Learn from every one and identify the technology,people,and process issues that need to be corrected.
• Create a framework to disable and enable features of your product.
• The implementation of state limits scalability and increases cost.
• Try to avoid session data completely,but when needed,consider putting the data in users browsers.
• Many Web servers or languages offer simple server-based session management,but these are often fraughtwith problems such as user affiliation with specific servers.Implementing a distributed cache allows you to store session data in your system and continue to scale.
• Use asynchronous communication techniques to ensure that each service and tier is as independent as possible.This allows the system to scale much farther than if all components are closely coupled together.
• Think about how you will need to monitor your application as you are designing it.