Articles

Learn from our experience developing the Deliveroo product.

Improving Password Security

Passwords are a pivotal tool in customer account security, however they are frequently at risk from “reuse” - people choose one or two passwords and then use them everywhere, which brings a host of security problems…

Read more…


Determinating a Scavenger Hunt

The Deliveroos rose from the ashes of the experimental fire. Their war to grow the product had raged for decades, but the final battle would not be fought in the future. It would be fought here, in our present. Tonight…

Read more…


Data Sink

Our applications generate a lot of interesting data, but it’s not always simple to find the right way to collect it. We wanted to make it easier, so we went to the drawing board, and here’s what we’ve come up with.

Read more…


How to un-rickroll yourself

A story of how leaving your laptop unlocked can lose the entire morning.

Read more…


“I assess quality……therefore I am”

Friends, engineers, fellow food enthusiasts…lend me your ears. Before my interview with Deliveroo in November, I read some articles from the engineering blog and I promised myself that when I did start working for this amazing company, I would participate and write an article about all things QA…. I also had a little bet with Troy Harris. He fulfilled his end of the bargain so I’m fulfilling mine. In this blog, I’m going to talk about my Deliveroo Interview experience, the current QA process, taking responsibility, my typical working day and Brown Bag sessions.

Read more…


Hackday and the £17 soda

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

Read more…


Every service is an island

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.

Read more…


Scaling Rails 3.old

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.

Read more…


Optimising Redis storage, part two

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.

Read more…

Page 4 of 5