ReviseAlgo Logo

Real-World System Design with Kafka

Designing a Ride-Sharing Event Pipeline (Uber-style)

Ingesting and processing millions of GPS updates per second in real-time.

Introduction

When scaling location trackers for millions of users, traditional relational databases collapse under lock contention. A ride-sharing platform must ingest and route coordinates from thousands of active drivers in real-time. Designing a Ride-Sharing Event Pipeline leverages Kafka's high-throughput partitioning capabilities combined with geohash coordinate routing to stream pings seamlessly.

Why It Matters

A driver's location updates every 4 seconds. If location pings are written to a standard disk table with transactions, the database locks up, causing API failures and laggy user maps. Separating ingestion (Kafka) from storage and utilizing geohash partitioning ensures updates are processed concurrently, keeping dispatch calculations up to date.

Real-World Analogy

Think of this pipeline like a city traffic control center. Drivers continuously shout their location coordinates over radios. If one dispatcher tries to write all coordinates onto a single whiteboard (database lock), they fall behind immediately. Instead, the supervisor maps the city into neighborhood grids (geohashes) and assigns a dispatcher to each grid (partitions). Each driver's coordinate goes directly to the dispatcher of their current neighborhood grid, parallelizing incoming data.

How It Works

The location ingestion pipeline works in the following stages:

  1. Ingestion Gateway: Client-side apps publish JSON location payloads (latitude, longitude, driver ID) to a REST edge gateway.
  2. Geohash Indexing: The gateway computes a spatial geohash (e.g. dr5reg for Manhattan) from coordinates.
  3. Custom Partitioning: The producer writes the event using the geohash as the routing key, ensuring updates from the same area land on the same partition.
  4. Stream Processing: Consumer groups read location events, calculate spatial queries (matching nearby riders), and stream coordinates to rider clients via WebSocket channels.

Internal Architecture

Under high traffic, partitioning location events by driver ID creates a severe problem: matching a rider with nearby drivers requires querying coordinates across all partitions, introducing high latency. Enforcing a spatial index using Geohashes solves this. By routing location pings based on geohash keys, all drivers within the same physical region land on the identical partition. Dispatchers query a single partition to find matches, localizing processing.

Visual Explanation

Below is an ASCII representation showing spatial geohash routing from drivers to grid-specific Kafka partitions: 

 [Driver GPS Location] ──> (Lat: 40.71, Lng: -74.00) ──> [Geohash: dr5r]
                                                            │
                                                            ▼ (Routes by Key)
[Kafka Topic: locations] ──> [ Partition 0 (Key: dr5r) ] ──> Manhattan Dispatcher
                         ──> [ Partition 1 (Key: c21g) ] ──> Brooklyn Dispatcher

Practical Example

Here is a Java Producer code snippet showing how coordinates are geohashed and published to Kafka using a custom routing key:

Common Mistakes

  • Using Driver ID as the primary partition routing key: While this prevents concurrency issues for single-driver updates, it requires spatial matching systems to query every broker partition to locate nearby drivers, causing severe query latencies.
  • Selecting extremely small geohash keys: Using 9-character geohashes (accuracy ~4.7 meters) as routing keys. This creates millions of unique keys, distributing data too widely and preventing aggregation. Use 5 or 6-character geohashes instead.

Quick Quiz

Q1: Why is geohash partitioning preferred over random round-robin partitioning in location pipelines?

Because it groups location coordinates by geographic proximity onto the identical partition, allowing dispatcher consumers to calculate spatial matching localized to a single partition.

Q2: How does a 5-character geohash key help spatial databases search for nearby drivers?

It represents a ~4.9km x 4.9km bounding grid. Querying drivers that share the same geohash prefix returns all candidates within that neighborhood immediately.

Scenario-Based Challenge

The Challenge: Mitigating hot partitions during local rush-hour events

During a major sporting event or downtown rush hour, 80% of active drivers congregate in one spatial geohash grid. Because all updates for that geohash route to the identical partition, one broker becomes overloaded (hot partition), causing ingestion lag, while sibling brokers remain idle. How do you re-design your key strategy?

Solution Tip: Implement a compound routing key matching the geohash plus a modulo salt based on the driver's ID (e.g. dr5r_1, dr5r_2). This splits the traffic from the same geographic grid across a bounded group of partitions (e.g. 4 partitions), resolving the single-broker bottleneck while keeping the search space localized.

Debugging Exercise

During morning peak hours, the geolocation gateway logs frequent connection timeouts, and drivers report that their online status toggles between offline and active inside client apps.

The Fix: The ingestion gateway is bottlenecked. The Kafka producer is using synchronous sends or has a low buffer configuration, blocking the gateway threads. Change the producer config to write asynchronously using callbacks, increase the buffer pool memory via buffer.memory, and configure batch sends using batch.size=131072 (128KB) and linger.ms=20.

Interview Questions

1. How do you design client-side backpressure in a location tracker pipeline?

If the gateway returns an HTTP 429 status code or takes too long to respond, client apps should adjust update frequency (throttling location sends from 4 seconds down to 10 seconds) or write coordinates to a local sqlite buffer database.

2. Can you use Log Compaction on driver location topics to save disk storage?

Yes. By setting the topic cleanup policy to compact and partitioning by driver ID, Kafka deletes old location coordinates, keeping only the driver's absolute latest coordinate update, saving disk space.

Production Considerations

Implement WebSockets using a decoupled cluster (e.g. Node.js or Go gateway) that reads coordinates from a Kafka consumer group and broadcasts updates, preventing client connection management overhead on critical stream processors.