ETA Computation from Live Data

In one line: this is the answer to Lesson 2's second challenge, and it works through an elegant inversion — the users being navigated are the sensors that make navigation accurate for everyone else.

What the stream yields

Derived signal	Detail
Traffic density	High, medium, or low on specific roads
Average vehicle speeds	Observed movement between consecutive pings
Recurring patterns	Congestion on Highway ABC between 8–10 a.m.

This real-time data allows us to adjust the baseline ETA derived from static road data. For instance, if live data indicates high traffic, the system increases the ETA accordingly.

The users are the sensors — a crowdsourced feedback loop with a real cold-start problem

The tuple is (userID, timestamp, (latitude, longitude)). That is it — no traffic cameras, no road sensors, no external feed.

From a stream of positions over time you can derive speed by differencing, and from many users' speeds on the same road you get traffic density. The people using the product are the measurement infrastructure.

That is elegant and it has two consequences worth naming:

A cold-start problem. Accuracy depends on having enough users on a road. A busy highway has thousands of pings a minute and excellent data; a rural road at 3 a.m. may have none, so its ETA falls back to static speed limits — exactly where the estimate is least verifiable.

A feedback loop with the routing. If the system routes traffic away from a congested road, fewer users travel it, so you get less data about whether it is still congested. Route enough people onto an alternative and you may congest that, which you will observe — but only after sending them there.

This is genuinely the same shape as distributed logging's sampling problem: the observability of a thing depends on activity you are also influencing. Worth raising, because it is a subtlety most candidates miss.

Three signals on three timescales, and they are used differently

The derived signals are not interchangeable:

Current density is now — used to adjust an ETA for a trip starting immediately.

Average speeds are a medium-term aggregate — the typical speed on this road under current conditions, smoothing out individual variation.

Recurring patterns are historical — "Highway ABC is congested 8–10 a.m." This is the only one that supports prediction: for a trip starting in an hour, current density is irrelevant and the historical pattern for that hour is what matters.

That third one is what makes departure-time planning possible at all, and it explains Lesson 10's relational table storing edgeID, hourRange, and rush — historical patterns keyed by time window, which is a different store from live conditions.

A long trip needs all three: current conditions for the first stretch, and historical patterns for road segments you will not reach for two hours.

'Adjust the baseline ETA' means updating edge weights — which invalidates precomputation

The phrasing is mild and the consequence is not.

Lesson 2 modelled edges as weighted, with weights representing distance, time, or traffic. Adjusting an ETA means changing a weight.

But Lesson 5 precomputed shortest paths using those weights and cached the results, including ETAs. So a weight change potentially invalidates precomputed paths — not just their ETAs, but possibly which path is shortest, since a congested road may no longer be the fastest route.

That is why Lesson 11 has a graph preprocessing service that "recalculates paths on the updated graph." The precomputation is not a one-off; it is a continuously refreshed cache whose inputs keep moving.

And it is why Lesson 11 needs the transitory-versus-persistent distinction: recomputing a segment's paths every time a car stops at a light would be absurd, while ignoring a genuine multi-hour closure would make routes wrong.

The static structure is precomputed; the dynamic weights force continuous re-precomputation. That tension is the design's core operational cost.

Distance and ETA age at completely different rates

Lesson 5 cached three things per path: distance, ETA, and the vertex sequence. Live traffic affects them very differently:

Distance — unchanged. The road is the same length regardless of traffic.
Vertex sequence — usually unchanged, unless congestion is severe enough that a different path is now faster.
ETA — changes constantly.

So the cheapest correct approach is to keep the cached path and recompute only its ETA from current edge weights, rather than re-running shortest path. That is far less work and correct most of the time.

Re-running the path search is only necessary when weights change enough to reorder which route is fastest — which is a much rarer event than weights changing at all.

This is a useful refinement the design does not make explicitly, and it follows directly from noticing that the three cached fields have different volatility.

Key takeaway

The users being navigated are the sensors — a crowdsourced loop with a cold start where data is thinnest and a feedback effect where routing traffic away reduces observability. Three signals on three timescales, with historical patterns being the only one that supports predicting a future departure. And "adjusting the ETA" means changing edge weights, which invalidates precomputation — though distance and path usually survive while only the ETA needs recomputing.

Three signals on three timescales, used in priority order. The fallback chain exists because of a real cold-start problem: a road nobody is currently driving produces no live signal at all.

The design so far returns a route. Production navigation returns several, and it keeps re-deciding.

Three things worth volunteering.

Top-K, not top-1. Users want alternatives, and the second-best route by distance is often the best by time. Computing K candidates costs little once the search is already bounded.

Ranking is by predicted duration, not distance. That is what makes the live traffic pipeline load-bearing rather than decorative — it changes which route wins, not just the number displayed.

Rerouting is the same query from a new origin. Conditions change mid-trip, so the system re-runs the bounded search from the driver's current position. This is why the ETA pipeline and the routing service have to be fast enough to run repeatedly, not just once per trip.

Interview signal by level

Level	What a strong answer sounds like
L4	"Collect traffic data and adjust the ETA when roads are busy."
L5	Explains the design: "we ingest location pings from users being navigated, derive speed and density from them, and use that to adjust edge weights and the baseline ETA."
Staff+	Names the loop and the invalidation: "the users are the sensors, so accuracy depends on density — a rural road at 3 a.m. falls back to speed limits. And there's a feedback effect: routing traffic away from congestion reduces our data about whether it's still congested. On the system side, adjusting an ETA means changing edge weights, which invalidates the precomputed paths — but distance and the path itself usually survive, so the cheap correct move is recomputing only the ETA and re-running shortest path just when weights reorder which route is fastest."

Next: how it is all stored.