With extensive experience in Digital Commerce, we constantly face challenges that drive us to innovate and find scalable solutions for our customers. Our priority is always to address their key business problems and ensure customer satisfaction and steady growth.
Recently, I worked on a project for a client to enhance their Order Management System for better stock visibility and control across the company. This article will delve into the crucial aspect of order management, printing and shipping, and explore the difficulties we encountered and the solution we devised.
What is Printing and Shipping module, and how is it an integral component of order processing?
When an online shopper places an order through an eCommerce platform, it involves three critcal steps at the backend, to fulfill the order: pick, pack, and ship. These three steps are handled by the order processing team in the warehouse.
The first and essential step for processing orders is to decide which order to process first. In the web application, when a customer places an order, he can select a courier service during the checkout process. It aids the buyer in getting orders as per his requirements and urgency. So, if a buyer needs his delivery done in a day, he will have to select the appropriate service, such as the express delivery option, and pay extra charges. Apart from that, different courier services have different times for picking up and shipping the items. In that case, the team needs to know which orders they should prioritize and prepare first so that the shipment can reach the destination at the earliest. However, for the team to figure out which orders need to be ready first without an automated system is time-consuming and error-prone.
The team faced a challenge in determining the priority of orders. To resolve this, we designed an order processing system that prioritizes orders based on courier schedules. Additionally, we incorporated intelligent picking to streamline the order picking process in large warehouses.
Here is a quick overview of the solution
To start with, we divided the order processing system into various blocks corresponding to different courier services that the buyer can select while placing the order. When an order comes into the system, the order gets added to the respective courier block chosen by the buyer.
Based on the courier block and its priority, the system generates a list of orders.
The order processing team can then view the orders, start processing them based on priority and begin printing the shipping labels and related items needed to prepare the package. The number of orders they can process at a time is 30-50, which saves them a lot of time.
Another issue that this system prevents is order mismanagement. Since several people might be involved in order processing, we must ensure that each order is processed only once. To make this happen, as soon as a user accesses a set of orders and starts processing them, those orders get locked until they are processed.
Once the processing is done, the system generates PDFs of orders, commercial and dangerous good invoices & shipping labels. After PDF is generated, the user gets the printout from the printer which they can use for packaging .
This solution was beneficial and efficient and worked perfectly fine. But with time, as the application scaled and the orders increased significantly, so did the number of courier services, and the system started encountering issues.
Two major issues:
1.) Loading speed: As the number of orders increased, the load speed of the order processing panel started to suffer dramatically. It would take about a minute to load and display the details.
The root cause of the issue was:
When an order was placed, we made an AJAX call at regular intervals and updated the order details in the system through the database. We performed various operations to display the intended order details, such as fetching the respective order data and sorting that data based on different priorities. But when there were several orders, fetching and sorting order details directly impacted the loading speed and caused delays in updating order details in the order management panel.
2.) Process several orders at a time: To ensure that each order is processed only once, we have implemented an order-locking mechanism. Initially, when handling 30-50 orders at a time, our existing solution of using MySQL queries to lock and reserve the orders worked well for us. But more orders in the pipeline increased the backend load due to increased database calls, impacting the overall system’s efficiency. In addition, we wanted the system to be able to process and print the shipping labels for 100 orders at a time without faltering.
In order to address these, here is what we did:
The proposed solution
1.) Using Elastic Search to prevent the load on the database
We implemented elastic search to fasten the order updation process in the admin panel. So instead of making that AJAX call to update our database, we used elastic search. Whenever the order is updated in our system, we update the latest data on ElasticSearch and load orders directly from it. Since Elasticsearch serves as an index store for retrieving data pretty fast, it helped us with instant updation without increasing the load on our database. It also helped us make our system robust enough to handle the increasing order values. The load speed was reduced from 1 minute to 7-8 seconds.
2.) Implementing Redis to lock the orders until they are processed to prevent mismanagement
To make our system more efficient, we put in place a lock feature using Redis. This meant when an order was being processed by one person, it was locked using Redis and couldn’t be duplicated. This resulted in the system being able to handle 100 orders at once, lightening the load on the main database.
The solution successfully allowed the system to handle up to 500 orders daily. We’re always working on upgrades, like automating order picking through RPA, and have more improvements in the works. So keep an eye out for updates on our journey to a future-proof system.