Presentation: The Distributed Pit of Success @Deliveroo



2:55pm - 3:45pm

Day of week:



Key Takeaways

  • Understand that microservices aren’t necessarily the best way of splitting apart a monolith - data needs to be owned
  • Learn about the differences between a data bus and an event bus
  • Discover how HATEOS and REST can be used to structure communications between systems


In just two years Deliveroo has expanded from central London to hundreds of cities in twelve countries, and the engineering team has grown at a similar rate. To allow us to continue innovating rapidly we need to be able to scale the team horizontally. But building distributed systems is hard, and typically requires hordes of very senior engineers with many years of experience and past failures behind them. This talk covers how Deliveroo is using domain driven design principles and powerful building blocks to remove this limitation and allow engineers of any level to quickly and successfully deploy new systems into production.


What do you work on?

Deliveroo is four years old now; a couple of years ago we were only delivering in cental London - but since we've expanded to over 12 countries and 3 continents.

When I joined we were running on a single server; now we’re running on a ruby stack across hundreds of machines.

How many developers work on the platform?

There are around 100 developers working on the product, which is primarily still a monolith. It is being broken out into a federation services, but this is an early-stage transform.

What’s the focus of the talk?

The theme is a report on how we’re splitting up our monolith into different services, some of the architecture that we’re moving into, and some of the problems that we found along the way. We’ll look into scaling issues with Ruby and dispatch, and how to monitor the state of the system and events.

We’re building an event bus (rather than a data bus) - services will have their have bounded contexts, but with a CRUD over the event bus. We’ll cover more of the details in the talk itself. We handle 10s of millions of events we process per day, because we’re getting pings from writers and restaurants. We need to make exceptions for this kind of data volume for streaming

What about microservices?

We think that microservices are flawed approach and we’ll cover the domain architecture and why we think that’s an improvement, applying strong ownership to avoid some of the data traps that end up with a massive data lake.

What is a macroservice?

The service owns the canonical data for the content it manages; for example, the identity service, it will manage not only the users, but will also manage sessions, oauth, and other identities such as external profiles, restaurants and so on. It owns everything it needs to know about the domain rather than being broken into different microservices. We use REST and HATEOS to show links between different services.

How are you scaling people?

We’ve scaled from 7 devs initially to 100 last year, and are aiming to move to 300 people later this year. The kinds of developers interested in the Ruby stack are mainly skewed to the junior and mid-range end; so we’re looking at how that affects our architecture. In other technologies, like the JVM, you find a lot more people skewed to the more senior end of the spectrum.

Who is the main persona for this talk?

This talk is aimed at technical leads and architects. Although the examples and experience are Ruby based, the architecture could be applied to any kind of language.

Speaker: Greg Beech

Lead Engineer @Deliveroo

Greg is a Lead Engineer at Deliveroo, currently responsible for rebuilding the live operations tooling. Prior to that he led the i18n/l10n and rollout of Deliveroo across the world and helped set up Deliveroo for Business. Before that, Greg was a Principal Engineer at blinkbox where he worked on much of the core platform, video encoding and streaming, and the Xbox application. When not working he enjoys motorbiking and mountain biking, as well as spending time with his girlfriend and son.

Find Greg Beech at

Similar Talks

CTO who understands the science around helping people do their best
Senior Software Engineer @IBM, Committer on Apache Aries
Distributed Systems Engineer Working on Cache @Twitter
Gold Badges Java, JVM, Memory, & Performance @StackOverflow / Lead developer of the OpenHFT project
Research Lead, Software Correctness @Galois


Conference for Professional Software Developers