Back

Case Study · Gojek

Driver Matching Engine

80ms p99 for 3M+ daily match decisions

Scroll to explore

Company

Gojek

Timeline

4 months · 2021

Role

Software Engineer

Team

3 Engineers

3M+

Daily Ride Requests

<80ms

Match Latency p99

+18%

Match Efficiency

5

Coverage Markets

The Problem

Matching was slow and unfair.

Gojek's driver assignment relied on a simple proximity-first algorithm: find the nearest driver, assign the ride. This ignored driver acceptance patterns, traffic density, and surge zones — resulting in long wait times during peaks, driver churning on bad assignments, and a mismatch score that hurt both sides of the marketplace.

The Solution

A scoring model, not a distance sort.

We replaced the proximity sort with a multi-factor scoring function. Each candidate driver receives a composite score based on geospatial distance, historical acceptance rate, time-of-day surge factor, and driver tier. Scores are precomputed and cached in Redis geohashes, enabling sub-100ms lookups even at peak traffic.

  • gRPC service with sub-10ms internal SLA
  • Redis Geo commands for driver position store
  • Python scoring service with configurable weights
  • A/B test framework for scoring model experiments

Results

The impact.

+18%

Match efficiency

80ms

p99 match latency

+12%

Driver acceptance rate

−23%

Customer wait time

Technology Stack

PythongRPCRedisGCPPostgreSQLDocker
Done.

That's the story.

View on GitHub