Thinking about Distributed System (from Rails point of view)
Often, a Rails developer does not think about Scalability.
People pick up Rails because it is a web application framework “for the rest of people”. In another word, what DHH (creator of Rails) provides is “good enough” for most of small to mid sized applications.
After all, what hinders your application from growing is not high DB reads/writes your app will suffer, but more likely the failure in marketing, or bad UX. Often apps suck long before they hit the road of scaling.
Does it justify you not knowing the scalability strategy? I don’t think so. No matter how much you’re specialized in “App Prototyping” or “Fast iteration”, you, as an engineer, are needed with a hope that the product you’re creating will change the world.
Moreover, if you’re pursuing your career towards the goal of becoming a great engineer, sooner or later, you have to overcome this way of thinking.
Here, the book “Service Oriented Design with Rails” comes in handy. This book introduces how to think about your Rails app more than a single hosted web app with single RDB managing application states.
Its primary focus is to introduce you a thinking in “services”, where each service has its own bounded context, and treating them as “nicely encapsulated actors”.
While the term “Service Oriented Design” might not sound familiar to you as a developer, you could think of services as a natural extension of object oriented design, encapsulation and message passing happing in a bigger scale (often over the network).
The book presents a few real-world application examples and used them here and there. I can’t agree more on the importance of examples as a way of engaging readers, but I somewhat felt they were only be used as a general explanation of different concepts.
The book would have been better if it carried one concrete example throughout the book, gradually breaking it into a “scaling” service oriented design.
Nonetheless, I do recommend this book to test your knowledge in the domain, but I also advise you to skim through the book to see how much in depth you feel like reading. For me, a few chapters (especially towards the end) definitely was worth a read.
The most interesting part for me was the pattern the author calls as “Synchronous Read, Asynchronous Write” pattern (SR/AW).
This is somewhat the solution to the CAP theorem. In distributed system, Consistency, Availability, Partition Tolerance cannot be met all 3 at the same time. (meaning pursuing 1 while maintaining the other 2 qualities is *proven* to be a failure).
With this taken into account, SR/AW pattern suggests that if you can live with “eventual consistency” instead of real-time consistency, then C (it’s a weak C) and AP can be met at the same time.
Also the author emphasizes Read and Write needs different strategy for optimization (caching for reads, NoSQL for writes, namely), so choosing different strategy for reads and writes makes sense for performance reason as well.
I will try to explain more in depth about CAP theorem and Eventual Consistency (asynchronous write via message broker like RabbitMQ) if there’s a sequel to this post (based on the reaction).
But for now, I hope this post interests Ruby developers who are curious about distributed systems (and service oriented architecture).
See you next time!