These docs are for v1.1. Click to read the latest docs for v2.0.
improved

Launching our v2 of the Solvice API

We are so happy to announce the launch of our v2 of the Solvice API. This new version is a major update of our API and includes a lot of new features. This document will give you an overview of the changes and new features.

TLDR: What is new and why should you switch now?

  1. 🚀 Major update of the performance of the solvers (up to 10x faster)
  2. ↔️ Job relations: defining jobs that depend on each other. Think of a job that can only start when another job is finished. Or a job that has to be performed at the same time as another job.
  3. 📈 Scale. In v1, we had a limit of 3000 jobs per problem. In v2, we are proud to confirm that we can solve huge last mile delivery cases of up to 15000 jobs.

Why we set out to rebuild our API

Building APIs is tough, especially when you are building a product that is still evolving. We have been building our new API for over one year now and we have learned a lot in the process. Our v1 was always built with backward compatibility in mind but this also meant that we had to make some compromises. There were poorly chosen property names and we had to make some choices that we would not have made if we had started from scratch. All of that lead us to the decision to rebuild our API from scratch.

Another reason is that we wanted to move to a completely serverless based architecture in order to be able to scale our platform to handle even bigger problems. This meant that we had to rebuild our API anyway. So we decided to take the opportunity to rebuild our API from scratch and to make it even better than before.

📘

You can find the migration path from v1 to v2 in the documentation

❗️

The v1 will be deprecated on 1st of January 2025

Performance

We have been working hard on improving the performance of our solvers. We have been able to improve the performance of our solvers by up to 5x. This means that we can solve your problems faster and that we can solve bigger problems.
But what does a faster solver mean? It means that we can check many more potential solutions per millisecond. Right now, we can check up to 500 solutions per millisecond coming from 100 solutions per ms. That means that we will reach higher quality solutions sooner and also reach the potential optimium (with heuristics you never know) faster.

V2 improvements

In this graph, you can see the performance improvements of our v2 solver compared to our v1 solver. The x-axis represents the solve time while the y-axis represents the quality of the solution (inverted because of the score).
Having a solver that is 5x faster will definitely not ensure you will get solutions 5x faster.
However, it will ensure that you will get better solutions in the same time. How much better is difficult to say because it depends on the problem. But we have seen improvements of up to 5% in some cases.

Job relations

In v1, we had a concept of job relations. However, this was limited to a single relation between two jobs. In v2, we have extended this concept to allow for multiple relations between jobs. This allows you to define complex relations between jobs.
For a more detailed explanation of the job relations, please check out our documentation.

There are many types of relations that you can define between jobs. Here is a list of the most common ones:

  • SEQUENCE: the jobs need to be visited in the given order
  • DIRECT_SEQUENCE: the jobs need to be visited in the given order, one after the other
  • SAME_TRIP: the jobs need to be visited in the same trip, the sequence does not matter
  • SAME_TIME: the jobs need to be visited at the same time, the assigned resource will obviously be different
  • PICKUP_AND_DELIVERY: the jobs need to be in the same trip and the pickup needs to happen before the dropoff. (special case of job relation)
{
  "type": "SEQUENCE",
  "jobs": [
    "JOB-1",
    "JOB-2",
    "JOB-3"
  ]
}
{
  "type": "DIRECT_SEQUENCE",
  "jobs": [
    "JOB-5",
    "JOB-6"
  ]
}
{
  "type": "SAME_TIME",
  "jobs": [
    "JOB-5",
    "JOB-6"
  ]
}
{
  "type": "PICKUP_AND_DELIVERY",
  "jobs": [
    "JOB-9",
    "JOB-10"
  ]
}

Scale

In v1, we had a limit of 3000 jobs per problem. In v2, we are proud to confirm that we can solve huge last mile delivery cases of up to 15000 jobs. This is a huge improvement and we are very proud of it.
Like most vrp solvers, we tackle this by first clustering the problem into different areas. We then solve each area separately and then merge the solutions together. This allows us to solve huge problems in a reasonable amount of time.

Want to do clustering yourself? Start by checking out the k-means clustering algorithm. Given a set of positions and a predefined number of clusters, it will return the clusters.
A big advantage of this algorithm is that it is very fast. It is also very easy to implement yourself. You can find a lot of implementations online.
However, the algorithm does not take into account the capacity of the resources. If you add this to the equation, it becomes an NP-hard problem. This means that it is very difficult to find an optimal solution in a reasonable amount of time.