Logistic software

We decided to rewrite the existing logic 1 to 1 into a new service, then the logistics service called our service synchronously, passing the necessary data to calculate the dynamic time. After we compared two forecasts, and if they differed by n seconds, then we displayed these differences in the log. Thus, we were able to test the code that we migrated and further refuse to calculate dynamic time in the logistics service.

Within a few months, the logic inside our service began to acquire code. In DC, many services have moved to Kafka to communicate using the asynchronous model. We also decided to abandon the synchronous call from the logistics service and switched to asynchronous work. That is, we separated the stage of assigning a courier and creating a forecast for the order.

The process was as follows: when a courier was assigned to an order, our service took this event from the topic, calculated the forecasts, and sent the forecast event to another topic, where it updated the current forecast for the order in the logistics database.

But here the question may arise, what time should be shown at the moment when the courier has not yet been assigned or the event from the topic has not yet arrived?

Now we use the zone time for such cases. The same time that was at the beginning of the article and from which we began to introduce improvements. This is the so-called time "on issue", which the client sees in the restaurant card. We also use it as a fallback logic, if for some reason the service failed to create a forecast for the order.

The pick-up time is a little more difficult to predict, because at this stage we don't have a specific courier yet. But the guys from the neighboring team are experimenting with calculations based on statistics. I think they will soon write an article on Habré.

How do we forecast time?

In logistics delivery, as we have already found out, there are two terms: First mile and Last mile. But also within each order there are other segments, for example:

PickupTime - the time spent by the courier in the restaurant while the order is being prepared and packaged;

ClientLag - time spent at the client's place to transfer the order, including parking time.

Each order has a life cycle: creation, appointment of a courier, confirmation of the order by a courier, pickup from the restaurant and delivery to the client.

Before the formation of our team, the first attempts were made to calculate the dynamic time of forecasts in logistics services. They consisted in counting the time from the appointment of the order to the courier and recalculating it when the courier picks up the order from the restaurant. Thus, we tried to correct the First mile and Last mile. Since the results were good, we continued to move in this direction.

The first step was to move the logic from the existing service to a new one written in Go. The deadlines were minimal, because at the same time we needed to support one of the functionalities for rolling out the feature of the team that auto-assigns couriers.