An order tracker for engineers

James Roberts
Dec 14, 2021 · 4 min read

Here at Gousto we are aiming to become the UK’s most loved way to eat dinner. A key pillar of this is convenience for our customers by delivering them our recipe boxes directly to their homes. As soon as a customer order leaves our factory they are issued with a tracking number so they can trace their order all the way from the factory to their front door. But from an engineering perspective, a customer order does not begin when it leaves the factory it begins when it is automatically generated by our subscription service, for subscription customers, or when ‘one off orders’ are placed through our website or apps. So how do we track that order from generation, through our systems, to it leaving our factory?

Brief summary of the Gousto order pipeline

As you can see each component can operate in isolation without any knowledge of any other component in the system.

This distributed architecture offers us many benefits but one challenge it does pose is how do we track an order through this pipeline and how do we know if any problems are occurring within it?

An order tracker for engineers

As engineers we are responsible for monitoring our systems and ensuring they are doing what they suppose to do. The easiest solution to this problem would be to wait for a customer to complain their order hasn’t arrived and investigate what went wrong. Very reactive and a terrible customer experience right? By implementing our own tracker we can get a live view of our pipeline and ensure each order reaches its key states within our agreed SLA’s (Service Level Agreements). If it does not we can setup alerts and resolve the issues immediately and hopefully in a timely manner meaning the customer will still receive their box on time.

The order tracker service subscribes to the messages representing key states in our order flow and these are represented by columns in our tracker DB. In the example above this would be order-created , order-recipesadded and order-deliveryinfo . When we receive these messages we update the order record with a timestamp in the relevant column. This gives us a dataset showing when each order reaches its key states.

We now do two things with our data. Firstly we have created a UI that displays the report for the day’s batch of orders and shows how many orders have reached which state:

Secondly and most importantly we have introduced SLAs between each state and alerting around this. A query runs regularly on the database to calculate if there are any orders that have entered the pipeline but no timestamp has been recorded for a key state within the SLA. If this query returns any orders then an alarm is raised with the affected order and we can investigate what went wrong. This allows us to solve issues proactively.

Next steps:
At Gousto we work in an iterative approach and the current tracker is the result of a couple of early iterations. We have many ideas to extend this tool further such as adding individual order tracking to the UI, adding more granular order states and improving the look and feel of the UI. But working in this iterative approach allows us to release the key value as early as possible.

Gousto Engineering & Data

Gousto Engineering & Data Blog