How We Handled The Communication With The Conveyor System
Today, I would like to talk about the approach we follow to communicate with the conveyor system, which plays an important role in the warehouse management system at Trendyol.
What is a conveyor system?
Conveyor systems are mechanical vehicles that are frequently used in fulfillment centers that move objects from one location to another.
In Trendyol, we use a conveyor system provided by a 3rd party company for the transfer of baskets and packages within the warehouse operations. Since we have identified points that we can improve in the communication model we have already established with the conveyor system, we have decided to choose a new approach in communication with the conveyor.
Legacy communication with conveyor system
Previously, we are establishing an event-based communication model with the conveyor system. When the user transferred the package to the conveyor, we were producing an event to the relevant exchange via RabbitMQ as a result of calculations. The conveyor system provided direct access to our RabbitMQ cluster so that they could consume events from RabbitMQ. It was risky and undesirable for a 3rd party company to have full access to our RabbitMQ cluster. Also, we could not monitor the conveyor system sufficiently with this structure. We also wanted to remove our dependency on RabbitMQ as there are plans to migrate from RabbitMQ to Kafka company-wide. For all these reasons, we decided that we should proceed with a new structure.
Let’s take a look at the new structure
Since our main problem is that a 3rd party company has access to our RabbitMq cluster, we decided to solve this problem first. For this reason, we decided to switch from an event-based communication model to an API call-based communication model.
Communication had to be fast enough for the conveyor to work properly. Since the distance between the barcode reader and the chute was short in some parts of the conveyor, there was a risk that the package might miss its target if communication takes more time than approximately 400–500 ms. In case of a possible slowness in communication, the package will go to the end of the conveyor instead of the targeted location. Of course, since this would be an undesirable result, we took care to pay attention to performance while making our decisions.
In the old structure, we did not need to store the packages and their destinations, as we were producing events after the calculation. In the new structure, we needed to save the barcode-destination match, since the conveyor system will do an API call after the package has passed through the barcode reader. We examined the advantages and disadvantages of MSSQL and Couchbase for storing these data. Then we decided to keep the data as Key-Value in Couchbase. In this way, we can access the data very quickly through the ‘Key’ and are not affected by any incidents that will occur on the MSSQL cluster we are using immensely.
In addition, with the new system, we have made the transition from RabbitMQ to Kafka for asynchronous messaging. We stored the events we sent to Kafka on Elastic and then prepared a dashboard for the conveyor with Kibana.
Monitoring
In the old system, we had no way of knowing what happened to a package. With the new system, we decided to create a dashboard to find a solution to this problem. To create this dashboard, we have set special statuses for every occasion. The conveyor system sends the package status when the package drops from the chute and we log these events on Elastic. The package statuses that we identified were :
- Package dropped successfully
- The package entered the target chute line but the target chute was full
- The package could not enter the target chute line because the target chute line is full
- No response from our API ( Timeout etc...)
- The target chute destination for this package could not be found in the database
- The package’s barcode could not be read
- A mechanical error has occurred in the conveyor
After determining these package statuses, we completed our dashboard via Kibana. After the completion of this dashboard, we were able to fully monitor the journey of the package on the conveyor. At the same time, the dashboard was very useful in addressing the problem to the right place in case of incidents.
Data Product
The project team wanted to see the logs going back at least 2 years to make analyses and improvements related to the conveyor. Since the data flow on the conveyor is too much and it would be very costly for us to store such long-term data, we started to consider alternative solutions. Then, as I mentioned in the diagram showing the new flow above, we started to feed all our conveyor events to the same topic and then created a data product over this topic. In this way, the project team was able to run queries via Big Query and we did not need to store data on Elastic for a long time.
Conclusion
We’re happy with the results of this new system. There are many other areas where we can improve and we will continue to focus on them. Don’t forget to review our job postings to be a part of this journey.
