Francesco Cesarini - Designing for Scalability with Erlang/OTP

Please address comments and questions concerning this book to the publisher:

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at:

To comment or ask technical questions about this book, send email to:

For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com.

Find us on Facebook: http://facebook.com/oreilly

Follow us on Twitter: http://twitter.com/oreillymedia

Watch us on YouTube: http://www.youtube.com/oreillymedia

You need to implement a fault tolerant, scalable soft real time system with requirements for high availability. It has to be event driven and react to external stimulus, load and failure. It must always be responsive. You have heard, rightfully so, of many success stories telling you Erlang is the right tool for the job. And indeed it isbut while Erlang is a powerful programming language, its not enough on its own to group these features all together and build complex reactive systems. To get the job done correctly, quickly and efficiently, you also need middleware, reusable libraries, tools, and design principles that tell you how to architect and distribute your system.

Our goal with this book is to explore multiple facets of scalability, as well as related topics such as concurrency, distribution, and fault tolerance, in the context of the Erlang programming language and its OTP framework. Erlang/OTP was created when the Ericsson Computer Science Laboratory (CSL) set out to investigate how they could efficiently develop the next generation of telecommunications systems in an industry where time to market was becoming critical. This was before the web, before tablets and smartphones, massively multiuser online gaming, messaging, and The Internet of Things.

At that time, the only systems that required the levels of scalability and fault tolerance we take for granted today were boring phone switches. They had to handle massive traffic spikes on New Years Eve, fulfill regulatory obligations for the availability of calls to emergency services, and avoid painfully expensive contractual penalties forced on the infrastructure suppliers who caused outages. In laymans terms, if you picked up the phone and did not hear the dial tone on the other end, you could be sure of two things: top level management got into serious trouble and the outage would make the front page news in the papers. No matter what, those switches were not allowed to fail. Even when components were failing, requests had to be handled.

As a result, telecoms switches had to react to failure as much as they had to react to load and internal events. So while the Ericsson Computer Science Lab did not set out to invent a programming language, the solution to the problem they were out to solve happened to be one. Its a great example of inventing a language that facilitates the task of solving specific, well-defined problems.