The problem
In most systems, latency is a quality attribute that can be tuned later. In mobility it is a functional requirement: a routing answer that arrives late is not a slow answer, it is an incorrect one, because the world it described has already moved. That inverts the usual order of architectural decisions, because it means the data model and the service boundaries have to be chosen for response time before they are chosen for anything else.
How we approached it
Draw service boundaries around latency budgets rather than around domain tidiness, and accept the duplication that follows as the price of meeting them.
Compute geospatial work against data that is continuously changing, which rules out designs that assume a stable snapshot.
Size infrastructure for peak rather than average demand, then attack the cost of that headroom directly instead of accepting it.
Make degradation explicit: decide in advance which answers the platform gives when an upstream dependency is unavailable.
Where it landed
A platform whose architecture is legible in terms of the response times it has to meet, where capacity headroom is a costed decision rather than an accident, and where dependency failure produces a defined behaviour instead of an outage.
No percentages or dollar figures appear above. These are our own products, and the structural changes described are checkable; a number attached to them would not be. We would rather publish the former than invent the latter.