An order tracker for engineers
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
At Gousto we use an event-based architecture following the pub/sub model. More information on this architecture can be found here. The order pipeline follows this architecture and a very simplified version of it is in the diagram below:
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
To solve this challenge we thought why should the customers have all the fun and built our own internal order tracker. The engineering order tracker tracks an order through key states in our internal pipeline just as the customer order tracker tracks a delivery through keys states in its delivery journey.
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-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.
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.