DEV Community: Roman Samoilov

If Rails Was Designed Today: The Operational Monolith

Roman Samoilov — Tue, 27 Jan 2026 14:59:54 +0000

Rails didn't get it wrong.

It got it right for the world it was born into.

In the mid-2000s, backend applications were mostly synchronous, request/response systems. Background jobs were rare, WebSockets didn't exist, observability wasn't a discipline, and "scale" usually meant adding more app servers behind a load balancer. In that world, Rails' core bet - optimizing relentlessly for developer productivity - was exactly the right one.

But the world changed. Modern backend systems are no longer just HTTP request handlers. They're long-lived processes juggling async I/O, background execution, real-time communication, eventing, and deep observability requirements. And most of that complexity didn't disappear - it just moved outside the framework.

Rails' quiet assumption

One of Rails' early assumptions is:

Production complexity lives outside the application.

Need background jobs? Add Sidekiq.
Need coordination? Add Redis.
Need concurrency? Add Async.
Need structured logging? Add Lograge.

This wasn't a mistake. It was a pragmatic trade-off at a time when Ruby had no mature async primitives and when keeping the framework small mattered more than absorbing operational concerns.

But the long-term consequence is familiar to anyone running a complex Rails backend today: your app is no longer a single system. It's a constellation of processes, queues, and coordination layers that must all be reasoned about together.

Rails stayed elegant by pushing complexity outward. Teams paid for that elegance later, in operations.

A different assumption

What if we start from a different premise?

Backend complexity is inevitable - so the framework should absorb as much of it as possible.

For a long time, the Ruby ecosystem didn't have a specific answer for this. We had Rails for productivity, and we had micro-frameworks for raw simplicity. But we lacked a framework designed specifically to handle the modern, high-concurrency, operationally complex world without abandoning the ergonomics of Ruby.

This is the philosophy behind Rage.

Rage is an API-only Ruby framework designed to explore what backend development looks like when we treat modern operational concerns as first-class instead of external integrations.

What this looks like in practice

If Rails was designed today - with fiber schedulers, async I/O, structured logging, and real-time APIs as givens - the architectural choices would look very different.

Concurrency as a foundation, not an escape hatch

Rage is fiber-first. HTTP handling, background jobs, and WebSockets all run inside the same async runtime, with the same object model and failure semantics. Async work isn't something you hand off to another system - it's just another execution path.

Background jobs as part of the application

Instead of assuming a separate worker fleet and queue infrastructure, Rage treats background execution as an in-process capability by default. Jobs are persisted to a write-ahead log on disk, providing delivery guarantees without Redis or a database.

That means fewer moving parts, fewer failure modes, and durability with zero setup - a backend that can start simple and scale outward only when necessary.

Observability as a framework contract

Rage provides a dedicated observability interface that lets developers measure and monitor what's happening inside the application - request handling, job execution, WebSocket connections. The framework sandboxes observability code: if your instrumentation has a bug, it won't crash your request handler or background job. Observability becomes a safe, first-class capability rather than something you hope doesn't interfere with production.

The unified runtime also enables deeper logging semantics. Request IDs aren’t just an HTTP concept - they automatically propagate to any background jobs enqueued during a request, ensuring all logs produced are tagged with the same parent request ID. This kind of cross-cutting observability is automatic in a unified runtime, but requires deliberate coordination when stitching together separate tools.

This isn't about more features. It's about acknowledging that observability is part of what a backend is, not something bolted on later.

Documentation as code

In a distributed world, the API contract is everything. Rage generates OpenAPI documentation through static analysis of your code. That means your API schema can be generated and validated in CI without spinning up the application. The schema isn't a separate file you have to maintain; it's a reflection of your actual routes and controllers, verifiable at build time.

One system first, distributed later

Thanks to a fiber-based architecture and direct inter-process communication, Rage can run a full-fledged backend - HTTP, jobs, WebSockets - in a single process or a multi-process cluster, without introducing Redis just to coordinate state.

Distribution becomes a scaling decision, not a starting requirement.

The monolith, redefined

In the Ruby community, monoliths are often praised as an antidote to microservice sprawl. But "monolith" is usually defined in terms of code structure rather than system behavior.

A Rails app with Sidekiq workers, Redis coordination, and WebSocket servers may live in one repository - but operationally, it's already distributed.

Rage starts from a different definition:

A monolith is a system that can be deployed, understood, and operated as a single unit.

Because HTTP handling, background jobs, async I/O, and WebSockets all live inside the same fiber-based runtime, a Rage backend can remain genuinely monolithic far longer - running comfortably on a single server without external coordination infrastructure.

That doesn't push teams toward microservices. It does the opposite. It allows teams to delay distribution until it's forced by scale, not assumed from day one.

In that sense, Rage is less API-first and more monolith-first - just without a template renderer attached. That's not a limitation. It's the entire point.

Follow along at https://x.com/codewithrage

Impractical Ruby Optimisations

Roman Samoilov — Tue, 30 Sep 2025 17:13:53 +0000

Earlier this year, I was working on an event bus for the Rage framework. The event bus was designed to allow publishing both synchronous and asynchronous events. With synchronous events, the request would wait for event subscribers to finish. With asynchronous events, subscribers would be executed after the request had been served.

But what happens if an application publishes a bunch of asynchronous events and then receives a SIGTERM? To prevent losing these events and to ensure they can be processed after a server restart, the framework needed to store asynchronous events in persistent storage.

By default, Rage would store asynchronous events on disk in an append-only log. This allowed for a seamless setup, eliminating the need for any specific configurations for the event bus to function.

Let's explore how the storage was implemented, walk through possible optimisations for an otherwise straightforward code, and see how seemingly minor code choices can significantly impact performance.

While working on the event bus, it evolved into something very different - a message queue. However, the code described in this article is still largely used within the framework.

Saving Data on Disk

Let's examine the following code, which stores asynchronous events on disk:

require "zlib"

class DiskBackend
 def initialize
   @file = File.open("storage/#{Time.now.strftime("%Y%m%d")}-#{Process.pid}", "a+b")
   @entries = {}
 end

 def add(event, subscribers)
   entry_ids = Array.new(subscribers.length) { generate_entry_id }
   serialized_event = Marshal.dump(event)

   subscribers.zip(entry_ids) do |subscriber, entry_id|
     entry = "add:#{entry_id}:#{subscriber}:#{serialized_event}"
     crc = Zlib.crc32(entry).to_s(16).rjust(8, "0")

     @file.write("#{crc}:#{entry}\n")
   end

   entry_ids.each { |entry_id| @entries[entry_id] = true }
 end

 private

 def generate_entry_id
   Process.clock_gettime(Process::CLOCK_MONOTONIC).to_s
 end
end

The DiskBackend class stores event subscribers in a file. Since each event can have multiple subscribers, the class generates a unique entry for each subscriber.

In the constructor, we open the storage file and initialise the @entries hash (more on this later). The add method then performs the following steps:

Generates unique IDs for all entries;
Serialises the event;
For each subscriber:
- Generates an entry in the format of add:<entryID>:<subscriber>:<event>;
- Generates a CRC32 signature for the entry;
- Writes the entry to the file;
- Updates the @entries hash with the list of generated entry IDs. This information is used during storage file rotation to identify in-progress events that need to be copied to a new storage file.

Let's now run a simple benchmark to see how the code performs:

RubyVM::YJIT.enable

require "benchmark/ips"
require_relative "disk_backend"

backend = DiskBackend.new

Benchmark.ips do |x|
 x.report("add") do
   backend.add(event, subscribers)
 end
end

On my machine, with Ruby 3.3.8, I get the following results:

ruby 3.3.8 (2025-04-09 revision b200bad6cd) +YJIT [arm64-darwin24]
Warming up --------------------------------------
                 add    44.335k i/100ms
Calculating -------------------------------------
                 add    226.405k (±16.5%) i/s    (4.42 μs/i) -      1.153M in   5.224209s

226k operations per second! That's good. But I think I can make it better.

Profiling

Let's profile this code and see if we can extract some useful information from there:

%self      total      self      wait     child     calls  name
26.80      1.343     1.343     0.000     0.000  1000000   <Module::Marshal>#dump        
16.33      1.286     0.818     0.000     0.468  1000000   Array#zip                     
 9.24      4.604     0.463     0.000     4.141  1000000   DiskBackend#add
 7.63      0.382     0.382     0.000     0.000  1000000   Float#to_s                    
 6.85      0.343     0.343     0.000     0.000  1000000   Hash#[]=                      
 6.15      5.011     0.308     0.000     4.703        1   Integer#times
 3.83      0.192     0.192     0.000     0.000  1000000   IO#write                      
 3.68      0.640     0.184     0.000     0.455  1000000   DiskBackend#generate_entry_id
 3.62      0.821     0.181     0.000     0.640  1000000   Array#initialize              
 3.44      0.516     0.172     0.000     0.343  1000000   Array#each                    
 2.46      0.944     0.123     0.000     0.821  1000000   <Class::Array>#new            
 1.90      0.095     0.095     0.000     0.000  1000000   Integer#to_s                  
 1.82      0.091     0.091     0.000     0.000  1000000   <Module::Zlib>#crc32          
 1.79      0.090     0.090     0.000     0.000  1000000   String#rjust                  
 1.45      0.073     0.073     0.000     0.000  1000000   <Module::Process>#clock_gettime

As expected, most of the time is spent serialising the event with Marshal.dump. One surprising observation, however, is the Float#to_s call coming from Process.clock_gettime(Process::CLOCK_MONOTONIC).to_s. This code consumes 7.63% of the total execution time.

On the one hand, this is understandable - we are converting the float to a string to then use it as part of the event entry written to the file. On the other hand, we don't have to do this, as the conversion will happen automatically when the number is written to a string anyway. What if we removed the to_s call then?

@@ -23,7 +23,7 @@ class DiskBackend
   private

   def generate_entry_id
-    Process.clock_gettime(Process::CLOCK_MONOTONIC).to_s
+    Process.clock_gettime(Process::CLOCK_MONOTONIC)
   end
 end

Let's run the benchmark again:

ruby 3.3.8 (2025-04-09 revision b200bad6cd) +YJIT [arm64-darwin24]
Warming up --------------------------------------
                add    64.575k i/100ms
Calculating -------------------------------------
                add    625.264k (± 6.5%) i/s    (1.60 μs/i) -      3.164M in   5.093242s

Whoa! Removing to_s, which doesn't affect functionality at all, and allowing Ruby to implicitly convert the float, increased the performance of our code by 2.76 times!

If you think this is the quirk of YJIT, it's not; the numbers are roughly the same without YJIT. And it's not even about implicit string conversions; the speed-up comes from this code:

entry_ids.each { |entry_id| @entries[entry_id] = true }

Turns out, setting elements with number keys in a hash is much more performant than setting elements with string keys. Less is more - lesson learnt.

Constant-time Writes

Reading the following section can lead to uncontrollable anger if you're a Product Manager.

Let's see if we can push the code a bit further. In our profiling results, we also see that the Hash#[]= call, used when populating the @entries hash, consumes 6.85% of the time.

Hashes are fast; setting elements in a hash has O(1) complexity. Moreover, we've already optimised that code by removing to_s. But what if we comment out the loop entirely?

@@ -17,7 +17,7 @@ class DiskBackend
       @file.write("#{crc}:#{entry}\n")
     end

-    entry_ids.each { |entry_id| @entries[entry_id] = true }
+    # entry_ids.each { |entry_id| @entries[entry_id] = true }
   end

   private

The benchmark shows the following results:

ruby 3.3.8 (2025-04-09 revision b200bad6cd) +YJIT [arm64-darwin24]
Warming up --------------------------------------
                add    66.647k i/100ms
Calculating -------------------------------------
                add    702.800k (± 2.4%) i/s    (1.42 μs/i) -      3.532M in   5.029299s

That's quite an improvement, but how do we get there if we still need the information in the @entries hash? We change the requirements, of course!

Instead of copying pending events during storage file rotation, we can modify the logic to rotate the storage file only when there are no in-progress events. This would require changes to the storage file rotation mechanism. On the plus side, we can now maintain a simple counter instead of a hash:

@@ -3,7 +3,7 @@ require "zlib"
 class DiskBackend
   def initialize
     @file = File.open("storage/#{Time.now.strftime("%Y%m%d")}-#{Process.pid}", "a+b")
-    @entries = {}
+    @pending_events = 0
   end

   def add(event, subscribers)
@@ -17,7 +17,7 @@ class DiskBackend
       @file.write("#{crc}:#{entry}\n")
     end

-    entry_ids.each { |entry_id| @entries[entry_id] = true }
+    @pending_events += entry_ids.length
   end

   private

The benchmark results for this version:

ruby 3.3.8 (2025-04-09 revision b200bad6cd) +YJIT [arm64-darwin24]
Warming up --------------------------------------
                add    67.455k i/100ms
Calculating -------------------------------------
                add    704.674k (± 0.7%) i/s    (1.42 μs/i) -      3.575M in   5.073673s

Micro-optimisations

There's one final optimisation I'd like to implement. Thinking about event buses, events are often quite specific. This means that, most of the time, an event has only one subscriber. Let's optimise the add method for this particular use case:

def add(event, subscribers)
  serialized_event = Marshal.dump(event)

  if subscribers.length == 1
    entry = "add:#{generate_entry_id}:#{subscribers[0]}:#{serialized_event}"
    crc = Zlib.crc32(entry).to_s(16).rjust(8, "0")

    @file.write("#{crc}:#{entry}\n")

    @pending_events += 1
  else
    entry_ids = Array.new(subscribers.length) { generate_entry_id }

    subscribers.zip(entry_ids) do |subscriber, entry_id|
      entry = "add:#{entry_id}:#{subscriber}:#{serialized_event}"
      crc = Zlib.crc32(entry).to_s(16).rjust(8, "0")

      @file.write("#{crc}:#{entry}\n")
    end

    @pending_events += entry_ids.length
  end
end

Yes, the code looks terrible, but this provides an additional 10% boost:

ruby 3.3.8 (2025-04-09 revision b200bad6cd) +YJIT [arm64-darwin24]
Warming up --------------------------------------
                add    75.275k i/100ms
Calculating -------------------------------------
                add    770.936k (± 0.7%) i/s    (1.30 μs/i) -      3.914M in   5.077604s

Wrapping Up

With several simple (and one ugly) changes, we improved the performance of our code by 3.4 times! As it often happens with performance optimisations, the most significant improvement came from the smallest and simplest change.

Does it matter though? Aren't all of these micro-optimisations? Well, yes and no.

Let's consider our @entries hash example, where we were inserting elements into a hash:

entry_ids.each { |entry_id| @entries[entry_id] = true }

In theory, Ruby can insert 16M elements per second into a hash:

RubyVM::YJIT.enable

require "benchmark/ips"

entries = {}

Benchmark.ips do |x|
 x.report("Hash#[]=") do
   entries[Process.clock_gettime(Process::CLOCK_MONOTONIC)] = true
 end
end

Results:

ruby 3.3.8 (2025-04-09 revision b200bad6cd) +YJIT [arm64-darwin24]
Warming up --------------------------------------
            Hash#[]     1.450M i/100ms
Calculating -------------------------------------
            Hash#[]     16.066M (± 6.4%) i/s   (62.24 ns/i) -     81.173M in   5.083554s

It can't possibly affect our code, which makes less than 1M ops/s, can it? Yet, this very call slows down our code by 12%! So much for micro-optimisations.

The good news is that you likely don't need to worry about this. When it comes to web development, it's far more important to write maintainable code that is easy to read and change. Performance is not nearly as critical as maintainability. Gems, however, are a very different thing.

Gems provide abstractions that should be not only convenient but highly efficient, too. This enables applications to scale and handle more load using the same slow-but-maintainable user-level code.

While most optimisations might seem insignificant, their cumulative impact can be significant, especially in areas like gem development. The difference between a few microseconds can translate into thousands of operations per second, directly influencing an application's ability to scale and handle increased load efficiently.

How I spent my summer vacation: making Rails 15 times faster

Roman Samoilov — Tue, 14 Nov 2023 14:34:14 +0000

Everyone knows Ruby is slow. But is that actually right?

Last summer, I started thinking about things I dislike about Rails. This is not something I usually think about, as Rails is one of my favourite technologies. Mostly because I think I’d end up with something very similar to Rails if I had to write my own framework.

Still, I wasn’t entirely happy with the changes made to the framework over the last few years. And with the ongoing issues like poor performance, I decided to think about what I would do differently.

Inspiration

One thing that has inspired me a lot is the talk Ryan Dahl gave at JSConf EU in 2018.

In that talk, Ryan, the creator of Node.js, talks about some of the mistakes he has made throughout the development of Node. He also talks about the fact that JavaScript today is almost another language compared to JavaScript from when Node.js was started.

He attempts to rethink the approach Node.js introduced and presents Deno.

Today, Deno is a mature project used by Slack and Github. But back in 2018, it was a barely working concept that nevertheless allowed Ryan to share his vision with the community.

I work as a Technical Lead and know that vision is key. This is something that caught me by surprise when I started leading teams - you don’t have to be the best developer on the team to lead. You don’t even have to be the biggest expert in the technology you work with. What matters most is knowing for a fact what needs to be done and how exactly this can be accomplished - a vision.

Vision

I spent last summer trying to shape my vision of modern web development with Ruby and defining principles to encompass in a new framework. A framework that would rethink some of the concepts we are all used to. And I have finally settled on the four points:

Rails-compatible API - there’s no need to invent a wheel because Rails’ public API is clean and easy to use. Creating something new would steepen the learning curve and result in people refusing to use the framework.

High performance - this point is the most controversial one. A popular belief in the Ruby world says, “We should use Ruby when we don’t need high performance and other technologies otherwise”. Unfortunately, this view naturally transforms into “we should use other technologies all the time”. An application likely won’t start working faster once you use a faster framework. However, a framework with less overhead would enable much easier and more effective scaling. And while Ruby is not the fastest language, it’s not as slow as it looks like when using Rails.

API-only - technologies like Hotwire are pretty exciting, but one part of building sustainable and reliable applications is using standard approaches. Using JavaScript to create Web UI is not only an industry standard but also an incredibly simple and fun way to build modern interactive applications.

Acceptance of modern Ruby - Ruby 3.0 with the support for non-blocking IO was released almost three years ago. Non-blocking IO is essential for every modern technology, and it’s a shame we still block an entire server thread while waiting on IO.

Result

These principles ended up being implemented in a project called rage-rb. With lean code, critical parts implemented in C, and async IO out of the box, it offers much greater performance than Rails while providing a similar API.

As much as my ultimate goal is to make it production-ready and get companies to use the framework, it is essentially a concept I’d like to use to share my vision with the community and find people who think the same.

I’ve got no illusions - Rails will be with us for a long time. But is there something that could be done better? Or maybe just differently? rage-rb is my take on answering these questions.

rage-rb / rage

Fast web framework compatible with Rails.

Rage

Rage is a high-performance framework compatible with Rails, featuring WebSocket support and automatic generation of OpenAPI documentation for your APIs. The framework is built on top of Iodine and is based on the following design principles:

Rails compatible API - Rails' API is clean, straightforward, and simply makes sense. It was one of the reasons why Rails was so successful in the past.
High performance - some think performance is not a major metric for a framework, but it's not true. Poor performance is a risk, and in today's world, companies refuse to use risky technologies.
API-only - separation of concerns is one of the most fundamental principles in software development. Backend and frontend are very different layers with different goals and paths to those goals. Separating BE code from FE code results in a much more sustainable architecture compared with classic Rails monoliths.
Acceptance of modern Ruby -…

View on GitHub