By Mohit Agrawal

Whenever a customer makes an order from Gojek’s food delivery service GoFood, we aim to ensure that their need for a fresh, satisfying meal is met quickly. When dealing with large order volumes across 400,000+ merchant partners, we wanted to ascertain upfront whether we would be able to reliably service each order. This is what we call serviceability.

In this post, we’ll break down Augur, our service which uses Machine Learning to figure out if a given food order is serviceable.

But First, The Problem

If a merchant accepts an order from a customer, and we are unable to find a driver partner to fulfil it, the order cost is met by Gojek. In this case, given the scale at which we operate, large failure rates can result in massive burn.

There can be two possible outcomes for any unserviceable order:

1. Customer makes an order, we don’t find a driver partner nearby, the customer cancels the order due to long waiting time, and we compensate the merchant.
2. Customer makes an order, we determine the order cannot be serviced, and inform the customer with an error message prior to relaying it on to the merchant.

Better to fail up than fail down, right?

Enter Augur

Augur is the service that would run a serviceability check when the customer checked out their order on GoFood.

This service was going to make a decision on the fate of our orders, it would require a Statistical Model that can classify/decide the probability of a given order being a Driver Not Found (DNF). Augur would be the first line of defence for GoFood products.

Architecture of Augur

The decision flow boils down to three different components :

1. Augur : The front of serviceability service
2. Axon : The decision taking unit. This component holds the model
3. Feature-Store : This holds different data features to help decide serviceability.

Flow (Overview)

1. Request Call comes to Augur service. We process it and infer the appropriate model to call out, features needed to do so, and get the model’s tag.
2. We query these feature values from the Feature Store, combined with info received from the Food Order management Service (OMS) request
3. The Feature Store returns the values
4. Feature values are used to create model request and call Axon running the specific model
5. Axon returns the decision with score values
6. Augur uses the score and decision and provides it to Food-OMS.

More on Internal Services and Flows

• Feature-processor : It listens to the aggregated feature values and stores them in the feature store.
• Axon : This service holds the stateless model logic that when fed with feature values, can give statistical decision on serviceability.

Populating the Feature Store Flow

Typically, all the different OMS’ publish their data in different data streams. Thanks to the efforts of our awesome Data Engineering team, we are able to do streaming aggregations and create aggregations jobs on these streams. These jobs listen in on the stream, and publish aggregates to a different stream which we listen in on using the Feature Processor. This is then stored in the Feature Store in an appropriate format.

Augur has helped us bridge a crucial gap in our order management capabilities, helping reduce burn but more importantly, ensuring our customers have a streamlined ordering experience on GoFood. 💚

(Thanks to Praveen Penumaka, Nipun Jindal and shubham gupta for their work on this project).