This content originally appeared on DEV Community and was authored by DEV Community
Ruby on Rails supports creating monolithic "distributed systems." It accomplishes this via ActiveJob, the framework's abstraction for background job processing. And while it may be evident to some, thinking of Rails as a distributed system frames the mental model for the following discussion.
The critical architectural component in the Rails toolbelt for managing background jobs is the backplane or data-bus which allows us to store metadata about expensive operations that should move off the critical path and be processed in the background. Redis is generally used as this backplane for serious Rails applications. It's a multipurpose in-memory data store that serves several functions: a cache, message broker, and database.
ActiveJob is a Rails library that saves metadata to the backplane and runs operations in the background. Sidekiq is another popular library that serves the same purpose. Sidekiq implements the ActiveJob interface and includes advanced features not available in ActiveJob.
While Rails is primarily a web framework, it transforms into a distributed system through purpose-driven deployments. A basic deployment may run on a single server and spawn separate processes for the web application and background workers. A more sophisticated deployment might run separate servers, one dedicated to the web application and one dedicated to background workers. We can scale deployments like this to large clusters of servers dedicated to each purpose.
Now consider that we can also isolate hardware to run specific types of background jobs. It's also possible to run multiple instances of Redis to further isolate different types of background work.
As you can see, Rails supports sophisticated options for purpose-driven deployments that comprise a distributed system defined within a monolithic codebase.
There are several reasons you might consider such solutions. For example:
- Limiting resource contention on a centralized database
- Constraining requests to third party API endpoints
- Partitioning customers to ensure a single user can't exhaust system resources and cause problems for everyone
- Isolating ETL processes to prevent disrupting production
Let's visualize the infrastructure for some of these scenarios.
Note that all of these scenarios are managed by a single monolithic Rails codebase. Team productivity is exceptionally high in a well-designed Rails monolith. Even if the code is more tightly coupled, it's a tradeoff worth considering. You get several benefits of service-oriented distributed systems without all the downsides.
In addition to being a great web framework, Rails is also a distributed systems platform that can help you craft pragmatic solutions to complex problems. Stay tuned for the next post covering how to structure a queueing system to manage all that background work.
This content originally appeared on DEV Community and was authored by DEV Community
DEV Community | Sciencx (2022-03-10T20:57:15+00:00) Distributed Systems with Rails. Retrieved from https://www.scien.cx/2022/03/10/distributed-systems-with-rails/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.