Chander Dhall - Scalability Patterns: Best Practices for Designing High Volume Websites

Any source code or other supplementary material referenced by the author in this book is available to readers on GitHub via the books product page, located at www.apress.com/9781484210741 . For more detailed information, please visit http://www.apress.com/source-code .

Over the course of my professional career, my team and I have rescued countless projects that were either running out of budget or were behind schedule. At the same time, we have created projects or augmented teams to help clients start projects from scratch and take them all the way to completion. The success of a project does not solely depend on hiring a couple of rock star architects or developers and assuming everything will fall into place. Success needs to be in the DNA of the team. Good software leaders inculcate the successful qualities in each and every member of the team.

This book is the result of a presentation I did for Microsoft Tech Ed in Barcelona, Spain, in 2014. While the concepts are not new, I believe when it comes to the scalability of a web-based system and scaling your database system, these principles are timeless.

When we talk about scaling our systems, microservices is considered as a panacea to all ills; however, there are many systems that may not need a complete microservices model. Whereas microservices brings agility to our systems, we may not have the need to deploy four times a day. We may not have systems that are written in different languages and frameworks that need to be part of the system we are building.

Even though this book talks about microservices, its just one of the patterns that we will explore. Understanding scalability patterns and whats good, bad, and ugly about all of those is the real aim of the book. Having worked with start-ups, mid-size corporations, and Fortune 500 companies with global presence, I been fortunate to see what works and what fails. Patterns change all the time, but principles are fundamental to the system that runs on them. If you were to use an RDBMS like Sql Server that is better for scaling up than scaling out, normalization would take precedence over duplication of the data. However, if you are using a No-Sql database like MongoDB that scales out easily, then duplication might take precedence over normalizing in certain cases where availability is important.

With the ever-increasing technologies and frameworks, enterprise architects and developers struggle with getting tied into legacy tech, which makes it harder for them to take advantage of better technologies that could have solved many of the problems they are facing. However, its not just the technologies or the tech stack. More importantly, its also the patterns and principles that are being used to architect the system. Its very easy to lose focus on the big picture, especially in big organizations where its easy for teams to be in siloes and become myopic about they are doing. While working with different companies, my team and I keep an eye on similar mistakes in approaches and strategies and try to disseminate the learnings to other people on the team and eventually to teams working at other clients. Its reasonable to make mistakes; however, the goal is to learn from these mistakes.

This book focuses on different patterns of scalability. The goal of the book is for you to understand the strengths and limitations of these patterns. Understanding of the underlying principles is the key to architecting, developing, deploying, and then maintaining a great system that is futuristic, easy, and less costly to maintain and has the best ROI. The book is not opinionated, and the goal is not to force opinions. Its a critical analysis of all the current practices I have witnessed in the last decade. The real goal is to expose and encourage a scientific way of thinking that is principle based. The principles change per technology. Functional programming languages cant be expected to be written with the same principles as object-oriented languages. Patterns are problem specific. We cannot use a Strategy Pattern to solve the same problem as a Factory Pattern.

Software development is an ever-evolving field. Change is the only constant we know. The key takeaway from the book is to understand the mistakes that have already been made and to learn from them. No solutions suggested in this book should be considered absolute or final. Im sure we will continue to see newer problems with each passing day, and the great tech community will continue to solve them with continued dedication. Knowledge, experience, agility, and continuous improvement are key components to making projects, teams, and companies successful.

I wish I could put all of that in a book, but as you know a book is just a way to express some of your opinions. With this book, I wish to spread ideas and hope to establish a relationship with the readers. In the social media world, its easy to connect and I hope you will reach out. I value your opinions, criticism, and suggestions. I had a great time writing this book. I hope you enjoy reading it.