Skip to main content

​
Architecture

Nobody’s location platform failed because they called the wrong endpoint. They failed because they called the right endpoint six hundred thousand times a day when one call would have done. Because a cache key omitted a tenant identifier. Because a routing constraint lived in a request builder instead of on a vehicle record, and a refactor dropped it. These pages are about those decisions.

​
Why this section exists

The guides tell you what an API does. The use cases tell you how to solve a business problem. Neither tells you why a system that works at ten vehicles collapses at two hundred, or why the migration that saved 60% on paper cost eighteen months of engineering. The pattern across every location system we have seen in production is the same: the expensive mistakes are architectural, they are made in week one, and they are discovered in month six by operations.
A useful test. Take your highest-volume location call and ask: what is the smallest unit of work that genuinely requires this? If the answer is “an event,” and you are calling it per packet, you have found the bug — and it is not in the code.

​
The four decisions that matter

Almost every location architecture question reduces to one of these. 1. What is the unit of work? A GPS packet is not an event. A keystroke is not a query. An address is not an order. Systems bill on the unit they call, and the default unit is nearly always too small. The reverse-geocode-per-ping problem, the autocomplete-per-keystroke problem, and the routing-call-per-page-load problem are the same problem wearing three hats. 2. Is this computation or lookup? A drive-time polygon is a computation. Testing whether a point is inside it is a lookup. The first belongs to a routing API, computed quarterly. The second belongs to your database, executed millions of times, for free. Teams that call an API for the second have built a spatial database with an invoice attached. 3. What is the latency budget, honestly? Nothing is waiting for a nightly geocoding job. Nothing is waiting for a trip to be map-matched. Nothing is waiting for a territory to be re-optimized. Real-time endpoints exist because sometimes a user is watching a spinner. Paying for that latency when nobody is watching is the second-largest avoidable cost in this domain. 4. Where does the constraint live? A truck’s height is a property of the truck. A hazmat class is a property of the load. A tenant’s vehicle profile is tenant data. Constraints that live in request builders get dropped in refactors, silently, and the response still returns 200.

​
What these pages assume

You have read the guides. You know what Matrix Routing does. You are not looking for parameter tables. You are deciding whether to build a queue, how to key a cache, what to shadow-write during a migration, and how to explain a bill to your CFO.

​
The pages

Routing vs Matrix

The loop that is costing you money, why it looks correct, and the decision tree.

Caching Geocoding Results

Normalization, invalidation, and the privacy question a permanent cache raises.

High-Volume Geocoding

Millions of addresses. Queues, retries, idempotency, and what to monitor.

Routing System Architecture

Gateway, queue, cache, failover. The reference design and where it bends.

Google Migration Architecture

Dual-running, shadow comparison, and the rollback you must test before you need it.

Multi-Tenant Location Platform

Isolation failure modes, quota allocation, and the cache key that leaks.

Cost Optimization Patterns

A taxonomy of the patterns that move a bill by orders of magnitude.

​
A principle worth stating plainly

Most location systems do not need most of a location platform. Materialize what you can. Cache what does not move. Batch what nobody waits for. Compute in your own database what your own database can compute. What remains — routing a constrained vehicle, solving a VRP, matching a trace to a road network — is genuinely hard, genuinely worth buying, and genuinely small as a fraction of the calls most systems make. The architecture is what separates those two categories.

Guides

API-level implementation guidance.

Use Cases

Business problems and their reference architectures.

​
HERE documentation

Need help designing or implementing a production HERE solution? Placematic helps engineering teams select the right HERE APIs, estimate usage, migrate from Google Maps and build production-ready geospatial systems. Talk to us.