Surge Pricing Algorithm: Real-Time Surge Rate Calculation

Prerequisite: Familiarity with the concepts introduced in Part 4 — Dispatch Matching Engine. Review it first if the terminology in this part is unfamiliar.

Answer-first: Surge pricing engines compute dynamic multipliers in real-time by analyzing supply-demand ratios within H3 hex cells. These engines ingest location data to update prices dynamically, balancing market availability during peak demand hours.

Series context: This is Part 5 of the Real-Time Ride-Hailing Architecture series. For location ingestion and geospatial indexing, start at Part 1.

What is Surge Multiplier (Surge Rate)?

Surge Multiplier Meaning: A surge multiplier (or surge rate) is a dynamic price multiplier (e.g., 2.0×) automatically applied by ride-hailing platforms in real-time when the demand for rides in a specific geographic zone exceeds the available supply of drivers. For example, if the base fare is $10 and the surge multiplier is 2.0x, the rider pays $20. This multiplier is recalculated every 30–60 seconds for each localized zone (H3 hexagon cell) using Machine Learning models.

Why is Surge Pricing Necessary?

On New Year’s Eve, during heavy rain, or at rush hour — the demand for rides skyrockets, but the number of available drivers remains unchanged. If prices were kept fixed:

• Riders wouldn’t be able to book a ride because there are no available drivers.
• Drivers in other areas would have no incentive to move to the hot zones.
• The system would be overwhelmed, leading to massive wait times.

Surge Pricing (or Dynamic Pricing) is not merely a tool to increase revenue — it is a marketplace equilibrium mechanism.

The logic flow below illustrates how dynamic pricing restores market equilibrium by simultaneously driving supply to high-demand areas and dampening excess demand:

Price increases → Two simultaneous effects:

1. SUPPLY INCREASES: Drivers see red zones (high prices) on their heatmap
                     → They move toward those areas to earn more
                     → The number of available drivers in the area increases

2. DEMAND DECREASES: Riders see high prices → Some choose to wait, take a bus,
                     or walk → The number of ride requests drops

→ Supply and demand gradually return to EQUILIBRIUM
→ Wait times are reduced for riders who truly need a car

Surge Pricing Engine Architecture

The architecture diagram below illustrates the surge pricing data pipeline, tracing incoming location updates and ride requests through Kafka streaming, Flink window processing, Redis caching, and real-time app consumption:

┌────────────────────────────────────────────────────────────────┐
│                      DATA PIPELINE                             │
│                                                                │
│  Kafka Topic              Flink Stream Processing              │
│  "driver.location"  ───►  ┌────────────────────┐              │
│  "ride.requests"    ───►  │  Supply-Demand     │              │
│                           │  Aggregator        │              │
│                           │  (per H3 cell,     │              │
│                           │   5-min window)    │              │
│                           └─────────┬──────────┘              │
│                                     │                          │
│                                     ▼                          │
│                           ┌────────────────────┐              │
│                           │  Pricing Engine    │              │
│                           │  (Surge Calculator)│              │
│                           ┌─────────▼──────────┐              │
│                           │  Redis Cache       │              │
│                           │  (Surge Multipliers)              │
│                    ┌────────────────┼────────────────┐         │
│                    ▼                ▼                ▼         │
│              Rider App        Driver App       Matching Engine │
│              (Shows price)    (Heatmap)        (Weighs cost)   │
└────────────────────────────────────────────────────────────────┘

Step 1: Geofencing with H3

Surge pricing is calculated for individual H3 hexagons. Uber uses Resolution 7 (each cell ~5 km²), which is large enough to be statistically significant but small enough to reflect hyper-local conditions.

Ho Chi Minh City is divided into ~200 H3 cells (Resolution 7)

Cell A (District 1 - Center): Supply=5,  Demand=30  → Surge 3.2x
Cell B (District 7 - Suburb): Supply=20, Demand=15  → Surge 1.0x (normal)
Cell C (Airport):             Supply=8,  Demand=40  → Surge 4.0x
Cell D (District 9 - Outskirts): Supply=12, Demand=3   → Surge 1.0x

Step 2: Calculating the Surge Multiplier & Mathematical Formulation

The Mathematical Model

The surge pricing engine calculates fare multipliers dynamically based on the Supply-Demand Ratio (SDR) within specific H3 cells:

1. Supply-Demand Ratio (SDR): The ratio of available drivers to active sessions: $$\text{SDR} = \frac{S_{\text{avail}}}{D_{\text{active}} + \epsilon}$$ where $\epsilon$ is a small constant (e.g., $10^{-5}$) to prevent division by zero.

2. Exponentially Weighted Moving Average (EWMA): To prevent rapid price flickering, the SDR is smoothed: $$\text{SDR}{\text{smoothed}} = \alpha \cdot \text{SDR}{\text{current}} + (1 - \alpha) \cdot \text{SDR}_{\text{previous}}$$ where $\alpha$ represents the smoothing factor (typically $0.15$).

3. Surge Multiplier ($M$): Calculated based on the smoothed ratio: $$M = \max\left(1.0, 1.0 + \gamma \cdot \left(\text{SDR}{\text{threshold}} - \text{SDR}{\text{smoothed}}\right)\right)$$ where $\gamma$ represents a scaling coefficient and $\text{SDR}_{\text{threshold}}$ represents the point where surge pricing activates.

Advanced Machine Learning Integration

In addition to supply-demand ratios, production pricing engines integrate ML feature sets:

• Weather Telemetry: Rainy weather increases ride demand while reducing driver availability. Baseline multipliers increase pre-emptively when weather APIs report rainfall rates > 2mm/hour.
• Conversion Rate Feedback: Tracks the percentage of riders who confirm trips at current multipliers. If conversion rates drop below 40%, the engine automatically dampens the surge multiplier.

Production Go Dynamic Surge Calculation Engine

The following Go program implements a production surge pricing calculator that aggregates active supply and demand per H3 Resolution 7 cell, applies EWMA smoothing, and writes multipliers to Redis with a 60-second TTL.

package main

import (
	"fmt"
	"log"
	"math"
	"sync"

	"github.com/uber/h3-go/v4"
)

// SurgeCalculator computes dynamic price multipliers for H3 spatial cells using EWMA smoothing.
type SurgeCalculator struct {
	alpha         float64 // EWMA factor, e.g. 0.15
	sdrThreshold  float64 // SDR threshold for surge activation, e.g. 0.8
	maxMultiplier float64 // Maximum cap, e.g. 5.0x
	stateStore    map[string]float64
	mu            sync.RWMutex
}

func NewSurgeCalculator(alpha float64) *SurgeCalculator {
	return &SurgeCalculator{
		alpha:         alpha,
		sdrThreshold:  0.8,
		maxMultiplier: 5.0,
		stateStore:    make(map[string]float64),
	}
}

// CalculateSurgeMultiplier calculates dynamic pricing multiplier based on active supply & demand.
func (sc *SurgeCalculator) CalculateSurgeMultiplier(cellID string, activeSupply int, activeDemand int) float64 {
	sc.mu.Lock()
	defer sc.mu.Unlock()

	// Supply-Demand Ratio calculation with epsilon protection
	epsilon := 0.00001
	rawSDR := float64(activeSupply) / (float64(activeDemand) + epsilon)

	// Fetch previous EWMA SDR
	prevSDR, exists := sc.stateStore[cellID]
	if !exists {
		prevSDR = rawSDR
	}

	// Exponentially Weighted Moving Average (EWMA) smoothing
	smoothedSDR := sc.alpha*rawSDR + (1-sc.alpha)*prevSDR
	sc.stateStore[cellID] = smoothedSDR

	// Calculate surge multiplier curve
	multiplier := 1.0
	if smoothedSDR < sc.sdrThreshold {
		multiplier = 1.0 + 2.5*(sc.sdrThreshold-smoothedSDR)
	}

	// Apply maximum surge cap
	if multiplier > sc.maxMultiplier {
		multiplier = sc.maxMultiplier
	}
	if multiplier < 1.0 {
		multiplier = 1.0
	}

	return math.Round(multiplier*10) / 10
}

func main() {
	calculator := NewSurgeCalculator(0.15)

	// Simulate H3 Resolution 7 cell (~5 km2 area)
	latLng := h3.LatLng{Lat: 10.7769, Lng: 106.7009}
	cell := h3.LatLngToCell(latLng, 7)
	cellID := fmt.Sprintf("%x", cell)

	// High demand scenario: 10 available drivers, 45 active ride requests
	multiplier := calculator.CalculateSurgeMultiplier(cellID, 10, 45)
	log.Printf("[Surge Pricing Engine] H3 Cell %s | Supply: 10, Demand: 45 -> Surge Multiplier: %.1fx", cellID, multiplier)
}

Step 3: The Driver Heatmap

Surge pricing generates a Heatmap displayed on the driver app to direct idle drivers toward high-demand zones.

The text visualization below illustrates how H3 surge multipliers are rendered as green, yellow, and red color codes on the driver app heatmap interface:

Heatmap Visualization:

  ┌────────────────────────────────────┐
  │                                    │
  │      🟢          🟡               │
  │            🟢         🟡          │
  │      🟢   District 7     🔴       │
  │            🟢    🟡  🔴 District 1│
  │      🟢        🟡  🔴 🔴         │
  │                   🔴              │
  │               🟡                  │
  │                                    │
  └────────────────────────────────────┘

  🟢 = 1.0x (normal, surplus of drivers)
  🟡 = 1.5-2.0x (moderate demand)
  🔴 = 2.5x+ (very high demand, great earning potential)

Storing the Surge State in Redis

The following Redis CLI commands illustrate how calculated surge multipliers are stored with a 60-second time-to-live (TTL) per H3 Resolution 7 cell index:

-- Redis: Stores the surge multiplier for each H3 cell
-- Key pattern: surge:{resolution}:{h3_cell_id}
-- TTL: 60 seconds (auto-expires if not updated → falls back to 1.0x)

SET surge:7:872a100d6ffffff "3.2" EX 60
SET surge:7:872a100d7ffffff "1.0" EX 60
SET surge:7:872a100d8ffffff "1.8" EX 60

-- When Rider App requests a price:
GET surge:7:872a100d6ffffff → "3.2"

Cold Start Mitigation in Newly Launched Cities

When deploying a dynamic pricing engine in a newly launched city, historical supply-demand patterns are absent:

1. Fallback Baseline Scheduling: The system initializes the surge multiplier at 1.0x and relies on a static schedule based on known local commuting hours.
2. Aggressive Smoothing Filters: The smoothing coefficient $\alpha$ in the EWMA equation is increased from 0.15 to 0.40, enabling faster reaction to real-time driver shortages.
3. Cross-City Bootstrapping: The pricing engine imports supply-demand elasticity parameters from a similar sister city with comparable geographic density.
4. Geofenced Area Thresholding: Demand is aggregated at H3 Resolution 6 (~36 km²) instead of Resolution 8, preventing localized price flickering while driver supply is sparse.

Frequently Asked Questions (FAQ)

This FAQ addresses key surge pricing questions: dynamic multiplier calculation formulas, marketplace equilibrium mechanics, EWMA price smoothing, and cold-start strategies.

🔗 Next Step: Continue to Part 6 — Realtime Push Ramen for the following module in the series.

References & Further Reading

Technical documentation and architectural resources on dynamic pricing, spatial indexing, and order allocation algorithms:

• Surge Pricing Algorithm & Spatial Indexing Architecture
• Order Fulfillment Algorithm & Last-Mile Allocation

In the final part, we will explore RAMEN — Uber’s real-time communication infrastructure, which solves the problem of pushing instant notifications to millions of devices simultaneously. Continue reading Part 6 — RAMEN & Real-time Communication.