Marketplace, Dispatch, and Logistics System Design Questions
Designing two-sided marketplaces and real-time operational platforms end to end, where the domain shapes the architecture: rider/driver and order/courier matching and dispatch (batched vs greedy assignment, single-assignment guarantees, re-matching, pooling), order, booking and inventory flows (holds, double-booking prevention, quote-to-checkout price honoring), surge and dynamic pricing systems (demand/supply signals, damping, caps and fairness controls, pricing rules), ETA and routing services (road graphs, time-dependent weights, map-matching, traffic fusion, degraded modes), proximity-driven matching over moving supply (geo-partitioned matchers, hotspot rebalancing, boundary effects), and real-time location tracking. Covers the canonical ride-hailing, food/parcel delivery, and booking marketplace case studies and the consistency, latency, and scale challenges they share. Generic building blocks used by these designs (caching, rate limiting, sagas, stream-processing internals, spatial index primitives, observability, deployment) are covered by their own topics.
MediumTechnical
73 practiced
You need to combine multiple traffic data providers with differing latencies, costs, and historical accuracies to produce a single ETA. Describe an algorithm to weight and fuse these sources in real time, including handling missing or conflicting data and scoring provider reliability over time.
Sample Answer
Direct answer
Fuse at the level of road segments (or corridors), not whole-trip ETAs (estimated times of arrival), and treat every provider as a noisy sensor with a learned bias (does it run systematically fast or slow?) and a learned error variance (how wrong is it typically?). Combine the bias-corrected estimates with inverse-variance weighting, where a source's weight is 1 divided by its expected squared error (statisticians call this the variance: the average of the squared gap between what a source reports and the truth, so a source that is occasionally very wrong scores worse than one that is mildly wrong just as often), and inflate a source's variance by how old its data is, so stale data automatically counts for less. Score reliability continuously against ground truth from our own fleet: the travel times our drivers actually take on those segments a few minutes later. Missing sources simply drop out of the weighted sum; conflicting sources are checked against the consensus of the others and excluded when they disagree far beyond their own stated error.
Why segments, and why inverse-variance
Providers differ in coverage (one is strong on highways, another on downtown streets), latency (seconds to minutes) and price. Fusing per segment lets each provider win where it is actually good. Inverse-variance weighting is the natural rule because, for independent unbiased estimates, it produces the combined estimate with the smallest possible variance, and it gives a fused uncertainty for free, which the ETA service can turn into a confidence range.
For segment travel time, provider i reports an estimate e_i. With learned bias b_i, learned error variance σ_i², and data age a_i seconds:
κ (seconds of error added per second of data age) is itself learned: fit how fast a provider's error grows with the age of its reading. Our own fleet's live probe data (map-matched traversal times, meaning each driver's raw GPS trace has already been snapped onto the road segment it most likely followed, from drivers on the road right now) enters the same formula as one more source, usually the best one on busy segments and absent on quiet ones.
Worked example
One downtown segment, κ = 0.1 s per second of age:
Provider
Reported (s)
Age
Learned σ
Learned bias
Corrected (s)
Effective σ (s)
Weight share
A
120
30 s
15 s
0
120
√(225 + 9) = 15.3
76.9%
B
150
5 min
25 s
+10 s (runs slow)
140
√(625 + 900) = 39.1
11.8%
C
100
10 s
40 s
0
100
√(1600 + 1) = 40.0
11.2%
Fused estimate: 120.1 s, fused σ = 13.4 s. Note that the fused σ is smaller than the best single source (15.3 s): B and C add information even though each alone is poor. B's five-minute-old reading contributes little because age inflated its variance from 625 to 1,525.
Missing data. If provider A times out, fuse B and C alone: 120.5 s with σ = 27.9 s. The estimate barely moves but the uncertainty doubles, and that uncertainty should flow through: the rider sees a wider ETA range, and dispatch adds margin. When every provider is missing, fall back to the historical profile for that segment, time of day and day of week, with its historical variance.
Conflicting data. For each source, compute how far it sits from the fused value of the other sources, in units of its own effective σ: this ratio, the gap divided by σ, is the source's z-score. In this example, all three are within about half a σ, so nothing is excluded. If provider C had instead reported 280 s (implausibly slow, for example a feed bug replaying a stale road-closure or detour reading), compare it against the fused value of A and B alone: their weights are 1/15.3² ≈ 0.00427 and 1/39.1² ≈ 0.00065, giving a fused estimate of (0.00427×120 + 0.00065×140) / (0.00427+0.00065) ≈ 122.7 s. C's z-score, using its own effective σ of 40.0 s, is (280 − 122.7) / 40.0 ≈ 3.9: past the 3-sigma cutoff, so it is excluded for this cycle. A milder miss does not necessarily clear that bar: if C had reported 20 s instead, the same calculation gives (122.7 − 20) / 40.0 ≈ 2.6, below 3, so it would not be excluded by this rule alone. That is a real limitation worth stating plainly: a provider with a wide effective σ, from a history of being consistently unreliable, is hard to catch on any single bad reading, because the exclusion rule is scaled by exactly the noisiness that makes it unreliable in the first place. Repeated exclusions trip a per-provider circuit breaker (after enough consecutive exclusions, stop calling that feed and fall back to the others for a cooldown period) so a broken feed stops being called even when no single reading clears the 3-sigma bar.
Scoring reliability over time
Ground truth arrives later: once our drivers traverse the segment, the map-matched traversal time is the truth for that time window. For each provider, per road class and time-of-day bucket, update exponentially weighted moving averages (EWMA: a running average where each new observation gets a fixed share α and older ones decay):
Bias: b ← (1 − α) b + α r, where r is the provider's error on that observation.
Variance: σ² ← (1 − α) σ² + α r².
Example with α = 0.05: provider A starts with σ = 15 s and bias 0. A single 40 s miss raises its variance from 225 to 0.95 × 225 + 0.05 × 1,600 = 293.75, so σ rises from 15.0 s to 17.1 s. Separately, one observation where A said 130 s and truth was 100 s (a 30 s overestimate) moves its bias from 0 to 0.05 × 30 = 1.5 s. With α = 0.05 an observation's influence halves after about 13.5 further observations, so a provider that degrades is down-weighted within a busy hour, while one bad reading cannot wreck its score.
Guard the scoring loop:
Only score where truth is solid: segments with enough of our own traversals in the window; otherwise skip rather than learn from noise.
Exclude our own probe data from the truth it is scored against, or the fleet source always looks perfect.
Keep per-bucket scores: a provider good on highways at night can be poor downtown at rush hour.
Cost and latency
Providers differ in price per request, so do not poll every provider for every segment. Poll the cheap or streaming sources broadly; call an expensive source only for segments on active routes (segments that some in-flight trip or pending dispatch will traverse in the next 15 minutes) where the fused σ is above the target. That is an example of a value-of-information rule: pay only when the extra source would materially shrink the uncertainty that users actually see, since the added accuracy is worth its cost only in that case.
For latency, fusion must never wait for the slowest provider: use each provider's last good reading, with its age reflected through κ, and update asynchronously as new data lands. The ETA request path reads the already-fused segment table.
Trade-offs and pitfalls
Averaging without bias correction: a provider that is consistently 10% slow drags every estimate; bias correction fixes that, weighting alone does not.
Assuming independence: two providers that license the same upstream feed have correlated errors; inverse-variance weighting then double-counts them. Detect it from the correlation of their residuals and merge them into one source.
Ground truth selection bias: our drivers avoid segments we believe are jammed, so jammed segments get fewer truth samples. Weight the scoring or supplement with provider-independent sources.
Recommendation: inverse-variance fusion with EWMA-learned bias and variance is simple, explainable and debuggable. Move to a learned model (gradient-boosted trees: an ensemble of many small decision trees, each trained to correct the errors the previous trees left behind, over provider readings, ages and context) only when you have enough truth data to beat it on held-out traffic (real segments and time windows kept aside from training, used only to check whether the model generalizes rather than having memorised the training data), and keep the simple fusion as the fallback.
That is every published Marketplace, Dispatch, and Logistics System Design question for Data Engineer so far. Browse the other topics in this category, or practice this one interactively.