It is not possible to merge .osrm* files.
There are tools out there for cutting and merging OSM extract, though.

But keep in mind you might run into issues like the following:

http://map.project-osrm.org/?z=8&center=49.694285%2C7.904663&loc=50.095917%2C6.350098&loc=49.310799%2C5.243225&hl=en&alt=0

Here a route from Germany to France takes you through Luxembourg (and the alternative takes you through Belgium). This works on the demo server, as we route on the whole planet. If you route on your Germany-France extract only, the "shortest route" will do a detour because you're forcing it to stay in the Germany-France extract (and now it's not be the actual shortest route anymore).

Here is a way to dynamically update edge weights:
https://github.com/Project-OSRM/osrm-backend/wiki/Traffic

There is currently no way to dynamically update the graph as in bringing in new changesets, though.

While it might be possible to adjust the extracting process in a way that serves your purpose (which itself might not be easy at all), the preprocessing phase (osrm-contract) has to run on the full set by default.

You could consider leaving the border vertices of region out of you contraction, so for region_1 - (set of connections) - region_2, you would only contract vertices that are in region_1 or region_2 but not the border vertices.

Doing so, you could still route on subsets of the graph and even correctly between regions. You will suffer a slowdown of the query, though and the contraction order might result in worse results, since it is restricted in its operation.
Country-borders might also not be the optimal choice for separation which could result in difficult to handle sizes...
All in all, without serious adjustments such a separation is not possible.

Thanks for the insights. I mentioned the Germany-France example only as an example. The actual case I'm investigating is using a regular grid of tiles where I would like the option of regenerating one or more tiles for updated data, or expanding an existing set with new tiles and having the routing engine work across the union of tiles.

Looking at the algorithm behind OSRM and some of the file structures, it looks like it could be theoretically possible to generate a full set but distribute parts of it that then match up again when multiple parts are combined, because of its hierarchical nature.

@georgevanvenrooij well, technically it is possible. The tiling approach will require immense amounts of memory if you end up with a lot of connections between the borders. The algorithm behind OSRM will essentially create square matrices in between these connections.

The approach has been done in the literature and we aim to implement something similar in the future. A naive approach will not work, though.

Just out of interest, do you want to use OSRM in a game engine? :) Because it starts to sound like it.

@daniel-j-h that is indeed the case, we're developing a custom engine for a game and OSRM is a candidate library that we are considering to use for routing queries along a road network.

@georgevanvenrooij in case of a game engine, the number of borders might be small enough for your ideas to work. The speed-up over basic algorithms in these cases will be far smaller than on a large continental road network.
Whether it works depends on the structure of the network and the size of your network and how structured it is. If many paths have similar length, or if there is a clear hierarchy.

@MoKob in our case the road network is actually based on real-world road networks, so the complexity and density of the roads is very similar.

One of the reasons for investigating OSRM is its speed, since we want to be able to determine routes for thousands of agents in a reasonable amount of time. Because of the setting chosen for the game (WW2 strategy), we can get away with less-than-optimal routes, simplified lua profiles and we don't require the entire world but still some big parts of it. It would be nice if distributing the database in parts would be possible, instead of requiring users the download the full database every time there is some kind of update.

Being a game, we can probably get away with cutting up query routes at tile borders ourselves, submitting the tiled pieces to separate library instances and then connecting the results at the borders, even if this generates sub-optimal results. That seems to be the easiest way forward if distributing one large database becomes an issue, although I have a feeling something more elegant should be possible by exploiting the hierarchical aspect of the algorithm, but I'm no expert on this matter.

Is the literature you mentioned available online somewhere? I'd love to read more about it.

@georgevanvenrooij there is quite the bit of research available (often also publicly). A good starting point is this TR, a survey paper by some of my former colleagues.

In general I would recommend reading on customizable contraction hierarchies and multi-level Dijkstra. Especially multi-level Dijkstra could be interesting for your goals. It would require a larger investment of engineering on you end, since I know of no open source project using any of these techniques.

There is also some work on performing updates for MLD on a GPU very fast. The list of publications is endless.

Closing here. Nothing actionable. Feel free to re-open if you should have follow-up questions.