Deliveroo, an online food delivery company, reimplemented performance-critical components of their Dispatcher service in Rust. The service is responsible for offering an order to a delivery rider, and is therefore called within every customer order transaction. As Deliveroo engineer Andrii Dmytrenko explains, this choice made possible a 4x performance improvement.
Being written mainly in Ruby, the Dispatcher proved not able to sustain the traffic growth Deliveroo services experienced, Dmytrenko writes. Additionally, this was preventing the adoption of more complex and computationally intensive dispatch algorithms. For these reasons, Deliveroo engineers set off to identify the biggest bottlenecks in the Dispatcher service and rewrite those parts in Rust.
As Dmytrenko explains, the migration to Rust was carried through progressively, starting with classes that had no dependencies on other parts of the Dispatcher and moving on. The biggest hurdle to overcome was ensuring Rust code could be called from Ruby. The approach they chose was based on wrapping a Ruby API around Rust classes and methods, for which they chose Rutie, a library for Rust-Ruby interoperability. One of the advantages of the wrapper-API approach was the possibility of reusing existing tests, which was of great help to ensure the new system was working correctly.
The performance improvements were quite large, writes Dmytrenko, with an overall 4x speedup in dispatching time and an astonishing 17x speedup in the sheer computation phase, which effectively enables the use of more sophisticated algorithms.
InfoQ spoke with Dmytrenko to learn more about the advantages they got from this rewrite and what it took to get there.
InfoQ: What were the biggest hurdles you found in the process of migrating the Dispatcher from Ruby to Rust?
Andrii Dmytrenko: I think the biggest hurdle was (and still is) a compilation time: it takes 20-30 seconds to compile the project in debug mode and run tests. And that is with just one file changed (dependencies already compiled).
Another one was that none of the Ruby interfacing libraries were "production-ready", so we had to use our fork of ruru and rubysys, where we merged several open PR and some of our own patches in one branch. Thankfully this is now more or less solved by rutie.
InfoQ: You mention performance as one of the driving motivations behind the move to Rust, but Rust is also aiming to be a "safe" language, with high memory safety. What was your experience in this regard? What Rust features helped getting to a running, bug-free software?
Dmytrenko: Rust has definitely given us a lot more confidence in our code because of its type system.
While migrating the code, we actually spotted few potential bugs in our Ruby implementation, which were quickly unveiled by the rust compiler. This was made possible by two Rust features:
If a value is nullable, you use
Option<T>and have to explicitly check if a value was provided.We used Enums where needed, and all enum variants have to be checked.
Memory safety is something that you quickly get used to when you work with garbage collected languages, but appreciate a lot when having to deal with lower-level languages.
InfoQ: Given the success of your migration to Rust for the Dispatcher, are you planning to migrate other components? Or what Ruby features are stopping you from doing this?
Dmytrenko: We would like to migrate more, but there are a few concerns. Rust is still not widely spread, so it lacks or has an incomplete implementation of some important components:
Background job processing (something like Sidekiq for Ruby). There are some libraries, but they don't seem to be complete or actively developed
Tracing (APM): we had to implement our own integration with Datadog APM
If you are interested in more details about how Deliveroo engineers used rutie in their Rust component we recommend reading Dmytrenko's complete post on the Deliveroo engineering blog.
