Engineering hyperlocal deliveries in India

Practo has started home delivery of medicines and other health-care essentials. This is Practo’s first step into the e-commerce and hyperlocal domain. We’ve launched this service in Bangalore with a key focus on on-time delivery.

On-time delivery is possible only if we maintain discipline from the time the order is placed till the time of delivery. We measure and optimize every step to the fullest. Our pharmacists get involved in every step of the transaction. This includes verification of prescription to the delivery of the drugs.

How does it work?

Our process begins the moment someone places the order and ends on delivery. Our system understands all the complexities of the real world. It mimics the state of the order in the lifecycle and also tracks exactly who is handling the order now. We need to understand the different parties involved in the lifecycle of an order. These entities are shops, suppliers, distributers, Family Pharmacists (FP), Zonal Pharmacists (ZP). One more important aspect is the location tracking of any order. We implemented polygons for this reason.

Polygon Creation.

Polygons

Let’s take the example of Bengaluru, where we started our operations. We divide the entire city into a multitude of polygons, which are either hand drawn or loaded via KML data. So in our system assume entire JP Nagar will be a polygon. The image on left shows how a polygon can be drawn from our interface. Each polygon needs a at least of 1 supplier, 1 ZP and 1 FP to be functional. Once we finish resource allocation we can switch on a polygon as serviceable. Note here that our polygons are not active as soon as we add the polygons to the map. This basic check prevents our system from taking in orders where we can’t service them. Currently, we do a serviceability check from the client end before placing the order. In the serviceability check, we run a point in polygon algorithm on all the polygons in our system.

Currently available slots in JP Nagar 7th Phase, Bengaluru, India

Slots

Each resource (aka ZP, FP etc) have a capacity slot definition. We have divided each day into 24 slots taking 1 hour each. Each resource has a working slot schedule on a weekly basis. So we can set working hours for each resource in our system for each specific day of the week. We also handle overriding slots at certain cases when we want to keep our services down (eg: Sunday). Our system lets us declare holidays for either full day or any specific part of a day. Above all our systems allows us to declare holidays for specific polygons or a set of polygons. The image of the left shows the currently available slots in an area. The strike out ones have already been filled up with orders. We also group slots so that it becomes easy for the user to understand.

Load

System assigns a max capacity of each resource for a single slot. If any of the resources, cross the limits then for that slot it becomes unserviceable.

Clients

Front end clients, can figure out whether we service in that location or not. If we service we will also store a set of slots in which we can deliver the supplies. Based on the user selected slot we deliver the supplies. In most cases a client will follow the below mentioned steps:

1. Fetch serviceability based on latitude and longitude
2. The client sends a lat and long value to the server. We run a point in polygon search algorithm using MySQL. It lets us know exactly which polygon does this client fall into. The server responds back with a serviceability response either true or false. This signifies whether we service in that location or not. Along with the response we also send back a polygon id for future use.
3. Add drugs and documents
4. Add flat number and landmark
5. Fetch available deliverable slots
6. The client makes a request to the slots API which is exposed to authenticated users only. While making a request the client sends a UUID, slot id and also sends us the polygon id which we had sent back while serviceability check. In our server, we temporarily lock a slot for that UUID for X amount of minutes. Locking is defined as temporarily holding one FP for that X minutes who was assigned to that polygon id. Let’s assume each FP has a max limit of 3 deliveries per slot, then once one UUID locks one FP that means now that FP is only left with 2 deliveries in that slot. We make an entry in Memcache with a TTL of X minutes which helps us put in place this locking mechanism. This X minute is configurable till the level of per polygon. After X minutes the lock is lifted and that slot is again available for someone else. If an order is placed during this X minutes for that slot then we persist the slot entry to our primary MySQL database. While placing the order the client needs to send the same UUID, based on which we identify whether there is a slot already locked or not.
7. Finally, post the entire order along with the same UUID
8. This entire system helps us keep track of load in a particular polygon and also the performance of our FPs (delivery agents). We also maintain a legacy system which helps us to auto schedule an order to the first available slot in a particular polygon when orders come in without UUID. This part of the system is maintained for older clients which we had released in the very early stages.

In my last words, I would like to say that this system is nowhere close to being in a final state and we have already started work on the next version of this system. We will phase this out within the end of this month. If you have any doubts, drop a DM on twitter at @debarko

Follow us on twitter for regular updates. If you liked this article, please hit the ❤ button to recommend it. This will help other Medium users find it.