Stories

Earlier this year, some awesome people who “read and write Ruby good” met at an event called RailsConf and delivered this poignant tweet in a bottle: “I love looking at my old code and hating it. It means I’m growing.”

This simple reflection by the brilliant Sandi Metz really resonated with my own - not just surrounding code quality, but the journey of developing a wider architectural awareness as well as the communication skills & empathy needed to build good software efficiently.

The Deliveroo Engineering team has come a long way incredibly fast and is growing even faster. Our Analytics team is undergoing similarly explosive growth, so I thought I’d talk to the newest members of that team and share why we’re so proud of our Engineering culture and how it’s grown with us. Here’s what we spoke about.

As part of a post on web concurrency in Rails, I’ve been running benchmarks to compare the Puma and Unicorn Ruby HTTP servers. Puma performs better than Unicorn in all tests that were either heavily IO-bound or that interleaved IO and CPU work. In the CPU-bound tests where Unicorn performed better than Puma, the gap was small enough that Puma can still be considered a very good choice.

Tracking authenticated user sessions can be implemented in Redis using setex with some serialised JSON. It works pretty well until you have to cope with millions, or even tens of millions of sessions where the memory usage and performance can suffer.

By using Redis data structures more effectively we can achieve a 70% reduction in memory usage, at the cost of both code and conceptual complexity. Is it worth it?

Split testing is a cornerstone of how we improve our products. While we usually run such tests for user-visible interface changes, this is an example of running a (successful!) multivariate test between CDNs.

The outcome is a 7% improvement in asset load times globally, translating into a +1% conversion on our site.