Build a routing service: production guide for modern geospatial systems

Basic knowledge of HTTP APIs, JSON, command-line tools, containers, and geographic coordinates.

A Linux, macOS, or equivalent environment capable of running Docker.

A versioned road-network extract in a format supported by the selected routing engine.

A documented transportation mode and routing profile.

A target geography, expected request volume, latency target, refresh policy, and operational owner.

A test set of known routes and edge cases, including inaccessible points and mode-specific restrictions.

Define a production routing service contract around modes, waypoints, units, geometry, errors, and limits.

Prepare a reproducible road-network graph from a versioned geographic extract.

Understand the OSRM extraction, partitioning, customization, and runtime stages.

Separate network distance and travel time from geometric proximity calculations.

Design refresh, validation, monitoring, rollback, attribution, and provenance workflows.

A known origin-destination request returns a successful response with distance and duration.

A coordinate-order test confirms that longitude and latitude are not accidentally reversed.

A no-route or invalid-coordinate test returns a stable application error rather than an unhandled engine failure.

At least one one-way, turn-restriction, bridge, ferry, or disconnected-network case is represented in the test suite.

The response geometry can be parsed by the intended client and uses the documented coordinate reference and order.

The running service exposes the expected graph release, engine version, and profile metadata through internal diagnostics.

A graph refresh can be rolled back without rebuilding the previous release.

If every request fails, verify that the graph preparation completed, that the runtime algorithm matches the preparation workflow, and that the container can read all generated files.

If routes are unexpectedly reversed or far away, inspect coordinate order. OSRM's documented coordinate syntax is longitude,latitude, not latitude,longitude. (project-osrm.org)

If a point cannot be routed, test the nearest-road operation, move the point only for diagnostic purposes, and determine whether the issue is snapping distance, access restrictions, a disconnected component, or the selected profile.

If the service is slow after requesting steps or annotations, compare response sizes and query options. Use the smallest response that satisfies the client and impose waypoint and timeout limits.

If a new extract changes many routes, compare source extract date, profile revision, engine version, and preprocessing artifacts before assuming the runtime is defective.

If memory or disk usage becomes a problem during graph generation, reduce the build geography, provision more resources, or select a processing strategy appropriate to the target region. Do not infer a universal hardware requirement from a small-city example.

If traffic updates do not change results, confirm that the update files are being generated, applied by the selected workflow, loaded by the running service, and tested against a route whose affected edges are known.

Add a geocoding boundary so address resolution and route computation remain independently testable.

Add a matrix endpoint for fleet assignment, service-area analysis, or facility comparison.

Store route requests and results with privacy-aware retention, source-release identifiers, and reproducibility metadata.

Combine network results with PostGIS proximity and containment queries for roads, buildings, public assets, environmental features, or operational records.

Evaluate whether a hosted routing provider, a self-hosted engine, or a hybrid design best fits your traffic, freshness, coverage, and compliance requirements.

Document OpenStreetMap attribution, data licensing, and the limits of any public tile or API services used alongside the routing stack.