Articles

We started at Deliveroo 4 months ago and have been building an API test framework which has now just completed stage 1. TL/DR We’re pretty happy here at Deliveroo, we’re learning, we’re having fun, we’re doing it at pace. Soda == Doughnuts

We had an incident yesterday. It wasn’t that bad as incidents go, but it got me really worried — it’s something that has the potential to become much worse as we move towards a distributed, multi-service world.

We’re not particularly proud that we are still using Rails 3.2, but we are extremely proud of scaling our traffic over the last few years. Our new services are built in Rails 5, but we still have a hefty chunk of functionality in our original Rails 3.x monolith. A rueful “rails 3.old” hits our slack channels as someone stumbles across an issue as they switch back to the monolith. Growing our business, features and team over the last few years has left little time to do a wholesale upgrade of the monolith platform. Here are some tactical things we’ve done to help it keep pace with our growth.

Counting unique users, checking if a credit card has already been used, or checking if this is a mobile user’s first visit ever — all of these require maintaining a large set of fingerprints (unique visitor ID, card fingerprint, IDFVs depending on the use case).

Because this usually needs to be queried very rapidly, Redis is naturally our store of choice. While using its SET feels obvious, what data structure to select? Are there memory/performance compromises?

This shows that while plain key/value is a safe bet, there are possible optimisations with hashes and traps to avoid with sets and sorted sets.

I’ve been with Deliveroo for over a year now, so it’s a good time to share what it’s like to be an Android developer here, how we do development, what tools we use, what are our practices etc. If you’re an engineer yourself maybe this article will help you decide if the way we work fits with yours - maybe you’ll be part of the team releasing our next Android app!

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?