Location-based order routing: where geo-routing breaks

Location-based order routing assigns each incoming order to the supplier best positioned to fulfil it based on the customer's location — typically nearest by drive-time, by polygon membership, or by postal-code coverage. That is the algorithm. The reason it is harder than the algorithm suggests is that 'best positioned to fulfil' requires four other parts of the platform to agree.

The supplier registry has to know each supplier's coverage. If coverage is modelled as a postal-code list, the registry stores arrays of codes; if it is a drive-time radius, the registry needs depot coordinates and a maximum-minutes value; if it is a polygon, the registry stores a geometry. Each model implies a different schema, and a marketplace operating in multiple countries usually ends up needing more than one.

Inventory visibility has to be current at routing time. A geo-router that picks the closest supplier but reads stock data from a six-hour-old export will route a fraction of orders to suppliers who cannot fulfil them. The supplier rejects, the customer waits, support gets the ticket. The fix sits upstream of the router: tightening how quickly stock changes reach the routing layer, not adding cleverness to the routing layer itself.

Pricing logic has to understand the routing decision. Delivery costs scale with distance. If pricing is computed before routing and shown to the customer upfront, the routing layer is constrained to choose a supplier whose distance matches what the customer already saw. If pricing is computed after routing, the customer can see a quote that changes between cart and checkout — a separate problem that surfaces as cart abandonment, not as a routing bug.

Customer-facing UX has to handle the case where routing produces no match. A customer enters an address outside any supplier's coverage and the platform should tell them so honestly, ideally before they fill the cart. Hiding the no-coverage case behind a generic error message is the fastest way to convert a routing limitation into a brand problem.

Each of these four systems has its own owner, its own deployment cycle, and its own data model. Treating geo-routing as a routing-team problem instead of a cross-team architectural decision is why most attempts to 'just add geography' turn into multi-quarter projects after launch.

Marketplace order routing falls into three patterns, and the right choice is determined by where delivery sits in the cost structure — not by which model is technically more sophisticated.

Round-robin assignment

Round-robin assigns orders to suppliers in rotation, weighted or unweighted. It is the simplest model to build and maintain because it requires no data about suppliers beyond who is active. The model fits digital-first marketplaces — courses, services, downloadable goods — where every supplier can fulfil from anywhere and the marginal cost of fulfilment is roughly the same across suppliers.

Round-robin breaks at the point where delivery distance starts to matter to the customer. A customer ordering bulky goods (firewood, furniture, white goods) cares whether the supplier is fifteen minutes away or four hours. Round-robin treats both as equivalent, and the marketplace pays the difference in support tickets.

Capacity-based assignment

Capacity-based routing assigns by current load — stock level, fulfilment capacity, or queue depth — and fits marketplaces where supplier availability varies more than supplier location does. Examples include digital service marketplaces with limited daily slots, freelance platforms, and ticketing platforms with per-vendor caps.

Capacity-based routing fails when it ignores geography for goods where geography matters. The router picks the supplier with the most available stock, who happens to sit on the other side of the country, while the supplier across town gets nothing.

Geo-based assignment

Geo-based routing assigns by location proximity or coverage membership. It is the most demanding to build because it requires coverage data per supplier, a real-time-enough inventory feed, and a routing layer that can fall back when the nearest match cannot fulfil.

The model fits physical-goods marketplaces where delivery cost is a meaningful fraction of order cost — local food, building materials, perishables, regulated goods, anything where same-day or same-week local delivery is part of the value.

The Norwegian Kortreistved firewood platform is built around this assignment pattern: orders go to the supplier nearest the customer's address, with routing logic owned by the platform rather than configured in a third-party tool. The architectural argument for keeping routing inside the platform — rather than inside a plugin's settings panel — is covered separately in why custom routing belongs in platform code.

None of the three models is universally correct. The deciding question is which dimension of the customer experience the assignment most affects: if it is wait time and distance, geo-based; if it is availability, capacity-based; if neither matters much, round-robin holds.

If a marketplace is already in the round-robin-with-distance-complaints stage, the next question is no longer whether to add geography but which model fits the operational reality and what it will cost in registry and inventory work. A focused architecture review with engineers who have shipped location-based routing into production can map the gap in a week. Discuss your routing architecture.

Once a marketplace commits to geo-based routing, the next architectural decision is how to model 'where a supplier covers' — and the three common models each fit different operational realities.

ZIP / postal code ranges

Coverage as a list of postal codes is the most precise model in jurisdictions with well-defined postal geography. A supplier declares which codes they serve, the router matches the customer's postal code against supplier coverage lists, and the assignment is either a direct hit or a no-match.

The strength is precision and query simplicity — a flat list, no spatial math required. The weakness is operational overhead. Every time postal authorities split or renumber a code, every supplier's coverage list has to be updated. In cross-border marketplaces, the admin team also has to understand multiple national systems and their quirks: Norwegian codes are four digits, US ZIPs are five with an optional four-digit ZIP+4 extension, UK postcodes mix letters and digits in a multi-part format, and codes that look numerically adjacent are not necessarily geographically adjacent.

Drive-time radius

Drive-time routing assigns based on whether the customer's address is within a maximum driving time — in minutes, not kilometres — from the supplier's depot. This matches real customer experience more closely than postal-code membership because two addresses with the same postal code can sit very different driving distances from a supplier.

Implementation requires integration with a routing/matrix API. Google Routes API: Compute Route Matrix computes drive-time and distance between many origin/destination pairs in a single request and is the most common building block; Mapbox Matrix API provides an equivalent service for teams already on its stack. The trade-off is cost per request and latency — drive-time computation at order time adds API time per routing decision, which adds up at high volume, so most production implementations cache or precompute by region.

Coverage polygons

Polygon coverage gives each supplier a custom geographic shape — a hand-drawn or computed region — and assigns by point-in-polygon membership. It is the most flexible model: a supplier can cover a city centre but not its suburbs, follow administrative boundaries, or carve around a body of water.

Flexibility costs operational complexity. Drawing and maintaining polygons requires an admin UI most plugins do not provide, plus a geometry data store the registry needs to support. PostGIS in PostgreSQL or equivalent spatial extensions are the standard backing technology. Polygon-based coverage is also harder to debug — when a customer is two metres outside a polygon, the no-match result looks identical to the result for a customer two kilometres outside.

supplier-coverage-models-geo-routing-marketplace

Supplier territory can be modelled through postal-code ranges, drive-time radius, or custom polygons. The right choice depends on delivery pattern, address quality, and how much operational control the marketplace needs.

The right model is determined by delivery pattern, with technical preference playing a smaller role:

Most production marketplaces do not pick one model exclusively. They start with the simplest fit (often postal codes), encounter limits at scale, and add a second model for edge cases — drive-time for same-day, polygon for specific suppliers who need finer control.

Most articles about geo-routing treat addresses as input, not as the problem. In a cross-border marketplace, the routing math fails as often because of bad address parsing as because of bad routing logic.

Address formats vary by country in ways that defeat generic input fields. Norwegian addresses use a four-digit postal code that precedes the city name. US addresses use a five-digit ZIP, sometimes with a hyphen-separated four-digit ZIP+4 suffix for higher precision. UK postcodes combine an outward code (letters and a digit) with an inward code (a digit and two letters). German addresses put the postal code before the city; Irish Eircodes are a seven-character alphanumeric system introduced in 2015 with no built-in geographic ordering. Some countries, including Ireland and parts of Latin America, have addresses without numbered street ranges at all — a building name, a townland, a county.

A marketplace operating in two countries inherits both systems. One in five inherits all of them. The supplier registry's coverage data has to match the format the customer submits, and the geocoder has to normalize input into something the spatial query layer understands.

The standard mechanism is geocoding — converting an address string into latitude/longitude coordinates and a structured address. Nominatim documentation, the open-source geocoder behind OpenStreetMap, exposes free-text address search and reverse geocoding with country-specific parsing. Commercial geocoders from Google, Mapbox, and HERE offer higher accuracy at cost. For most marketplaces, the choice is less about which provider and more about which addresses get cached: geocoding every order is expensive, geocoding once per customer address and reusing the coordinates is the operational pattern that scales.

Normalization also has to handle the cases geocoders do not. A Norwegian customer writes 'Bergen 5020' instead of '5020 Bergen' — most geocoders cope, but the supplier admin who entered coverage as '5020' may not get a hit if the platform stores the customer address verbatim. The fix is to canonicalise both sides — supplier coverage and customer address — through the same normalization pipeline before any comparison runs.

Geo-routing in production fails in ways that rarely show up in unit tests. Five edge cases account for most production tickets — each one tied to an architectural decision that was either made implicitly or deferred.

• The matched supplier is out of stock. The router finds the nearest supplier for the requested SKU, but the inventory feed is stale and the supplier cannot actually fulfil. The architectural choice is fallback behaviour: fail the order, route to the second-nearest, or hold for the original supplier's restock. None is correct universally — same-day delivery usually wants fall-through, scheduled delivery often wants hold-and-notify. The cause is rarely in the router itself; it sits in how inventory state reaches the routing layer, a pattern covered in detail in silent inventory drift between systems.
• The supplier is outside their declared coverage. A supplier declares coverage optimistically at onboarding — every postal code in the city — then rejects orders that come from the city's edge cases. The architectural fix is verification: orders flagged near a coverage boundary trigger a confirmation step or a coverage audit, and repeat rejections get rebated against future declarations.
• No supplier covers the customer. The customer enters an address with no coverage match. The UX choice is whether to surface this before the cart fills or at checkout. Surfacing early loses some traffic; surfacing late costs trust. The right answer depends on conversion economics, not on routing logic.
• Two suppliers with identical match scores. Two suppliers cover the same address with the same drive-time. Without a deterministic tiebreaker, routing behaves randomly and the support team cannot reproduce decisions. The fix is an explicit tiebreaker rule — capacity, recent performance, supplier-level priority — applied consistently and logged with each routing decision.
• Address normalization fails on edge input. A customer enters an address the geocoder cannot parse. The router defaults to no-match and the order silently fails. The architectural choice is fallback to human review: any address that fails normalization gets queued for a human operator instead of disappearing.

Each of these failure modes maps to a decision the architecture either makes or leaves to chance. Geo-routing implementations that look 'broken in production' almost always have one or two of these cases unhandled — not because the algorithm is wrong, but because the failure paths were never designed.

Not every marketplace benefits from geography in routing. Three patterns indicate that the investment will not pay back, and skipping geo-routing entirely is the right architectural call.

Digital-goods marketplaces — software licences, courses, downloadable content, subscriptions — have no fulfilment geography. The supplier registry can drop coverage entirely, and capacity-based or round-robin assignment is correct.

Drop-ship marketplaces where suppliers ship from a national fulfilment centre operate without per-supplier coverage. Distance is determined by the single fulfilment partner's network, not by supplier location. Adding geo-routing here creates complexity without changing the customer experience.

Marketplaces where delivery cost is small relative to product cost — luxury goods, specialised industrial parts, low-volume high-value items — usually do not see customer behaviour shift with delivery distance. The customer is selecting on rarity or fit, and the nearest supplier is not the deciding factor.

The honest test before investing in geo-routing is to look at the support ticket queue: if delivery-distance complaints sit below background noise, geography is not the priority. If they trend up month over month, the architecture is asking to be reviewed. A platform built without geographic routing can still add it later, while a registry that cannot model coverage will be harder to retrofit without touching every adjacent system. For teams considering a purpose-built multi-vendor marketplace, the question to settle before code is which assignment dimension matters most.

• Geo-routing is an architectural decision that touches the supplier registry, inventory visibility, pricing logic, and customer-facing UX before any routing math runs.
• The three routing models — round-robin, capacity-based, geo-based — fit different marketplace shapes; the deciding factor is whether delivery distance materially affects the customer experience.
• Postal-code, drive-time, and polygon coverage models each match different delivery patterns and have different operational costs; most production marketplaces eventually use more than one.
• Address normalization is its own engineering problem in cross-border marketplaces; canonicalising supplier coverage and customer addresses through the same pipeline prevents the most common silent failures.
• Five edge cases account for most production tickets — stale inventory, optimistic coverage declarations, no-coverage customers, tied scores, and normalization failures — and each maps to an architectural decision that should be made deliberately.

The four-system framing in this article is the most useful lens for teams who are starting to feel routing pain. The fix usually does not sit inside the router. It sits in the data model the router reads from — the supplier registry that has to hold coverage in a form the router can query, the inventory feed that has to be current enough to be useful, the pricing layer that has to align with routing decisions, and the customer-facing UX that has to tell the truth about availability before the cart fills.

Marketplaces that treat geo-routing as a routing-team problem ship implementations that work for the easy cases and fail at the edges. Marketplaces that treat it as a registry decision — what does our supplier model need to look like, and how does inventory get to the router fast enough — ship implementations that hold up at the scale that broke the old model. The choice between drive-time and polygon and postal-code coverage comes after that, and depends on what the goods are, what the delivery pattern is, and how much operational overhead the admin team can absorb.

For marketplaces already running into the support-ticket pattern this article opened with, the next step is usually an architectural review rather than another sprint of routing patches. Bluepes approaches this through marketplace platform engineering — scoping the registry, inventory, and routing layers as a single system to identify where a focused rebuild pays back faster than ongoing patches.

If the support queue has already started telling this story, a short conversation with engineers who have shipped location-based routing into production marketplaces will clarify whether the issue sits in the registry, the inventory feed, or the routing layer itself. Talk to the Bluepes engineering team.