I'm studying to develop an order management system and order dispatch for the couriers, this is a personal project, for study purposes.

Some important points about the deliverymen, they are bikers and they are on the street, moving, imagine something like Uber drivers, so it becomes necessary to receive their geolocation with a maximum difference of 10s.

Then, an order is created to collect in the geolocation "40.414449537495564, -79.98827788162178", a detail, it is possible to have N orders in the same geolocation.

The rule for shipping the order is simple, the closest delivery person will receive the order to pick up and deliver.

Imagine that the system is going to be managing orders and deliverers from all over the world, so the system needs to be able to manage all this information, and VERY FAST, so when an order is created, I need the fastest way to identify the deliverers closest to the order within a radius of up to 2km (1.2mil)

I've done some research on geospatial (or supported) databases like PostGIS, H3 and so on. With PostGIS, when creating 100,000 orders and 500,000 shippers, I had a significant loss of performance in identifying the shippers close to the order. Another crucial point, as the couriers are moving, the database update needs to be very fast and when I tried to update the database, in a table that only contains the courier ID + his geolocation, from many couriers to At the same time, the update took a long time, for that, I performed the tests in a multi-thread way and with the database on a server separate from my computer, on a machine with great configurations. I tried with different indices like k-tree.

I thought about using a "in-memory database", but since I'm thinking about running the system on N PODS from Kubernets, it doesn't work.

As for the H3, it was what I found most interesting, but I couldn't identify how to use it with this system that I'm studying to create.

So what I would like is ideas on how to better develop this system, techniques, data structures, in short, how to better architect this system, including database, REDIS for quick access, etc.


1 Answer 1


You don't have 500,000 shippers and 100,000 orders. Don't optimize for a case that you're not going to have. If you put in realistic numbers your performance will likely be ok.

It is much more important to think about good algorithms to dispatch shippers, as your simple rule won't work.

  • Hi! well.. this is not to be a realistic product, I will not turn this into a product to sell... so, these unrealistic senarios are exactly to test performance and algorithms :) Dec 5, 2021 at 6:29
  • mainly, with respect to performance to identify the closest deliverers ( get a list of deliverers ) Dec 5, 2021 at 6:32
  • What is the performance of matching one order as it is generated against 1000 shippers (which is probably a generous estimate for a medium sized metropolitan area)? If you can handle that with your current tools, your tools are good enough, stop worrying and optimizing prematurely! Dec 5, 2021 at 7:50
  • 1
    @CarlosRodrigues, if the whole thing is a fantasy, then what exactly will the results of the testing tell you? It's Willy Wonka software - pure imagination, where nothing works there like it does in reality, and nothing you learn there will correspond to reality.
    – Steve
    Dec 5, 2021 at 8:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.