Design a Real-Time Fuel Price Aggregator

Hard45 min
1 / 30
understanding8 min read

Problem Statement: Fuel Price Aggregator

Why aggregating fuel prices is a trust-and-freshness problem over data nobody owns.

Problem Statement: Fuel Price Aggregator

A fuel price aggregator answers one question fast: where is the cheapest fuel near me, right now? It looks trivial until you notice nobody owns the ground truth. The real price lives on a physical sign at each of ~150,000 stations and changes a few times a day at the station's discretion. We have to assemble a fresh, believable price map from sources that are individually unreliable.

There are two such sources. Bulk feeds come from fuel chains, payment networks, and data vendors — broad coverage but variable latency and gaps. Crowdsourced reports come from drivers who snap the price at the pump — fast and local but noisy, sometimes wrong, sometimes malicious. Neither alone is trustworthy; the system's job is to fuse them into a single current price per station and fuel grade, with a confidence we can stand behind.

Three problems define the design. Trust: is this report real, or a fat-finger, a stale photo, or a competitor's sabotage? Freshness: a correct price from 3 days ago is now wrong; how do we decay and expire? Geo: the dominant query is cheapest fuel within N miles of my location, which must return in well under 100 ms over a national station set.

The shape is overwhelmingly read-heavy. We ingest perhaps ~500,000 price reports/day, but serve millions of nearby-price queries/day from ~10 million users — a 10:1-plus read/write ratio that, just like a tracking page, pushes the whole design toward a precomputed, cached, geo-indexed read model fed by a trust-scoring ingestion pipeline.

Key Highlights

  • Nobody owns ground truth: prices live on physical signs at ~150K stations and change a few times a day
  • Fuse two unreliable sources — bulk feeds (broad, laggy) and crowd reports (fast, noisy/malicious)
  • Three problems: trust (is the report real?), freshness (decay/expire stale prices), geo (cheapest-near-me <100ms)
  • Read-heavy: ~500K reports/day in vs millions of nearby-price queries/day → cached, geo-indexed read model

Section Rescue Kit

Buzzwords to use:

Source fusionFreshness decay

Safe statements:

  • "I will design the trust-scoring ingestion first, then the cached geo read path on top of it."
  • "The core difficulty is that every input is unreliable, so confidence is a first-class output."
Design a Real-Time Fuel Price Aggregator - System Design | WinJob | WinJob