Ride Booking System Design (HLD & LLD)

A ride booking platform (for example, Uber or Ola) is a classic system design problem that evaluates the ability to design scalable, low-latency, highly available distributed systems.

Functional Requirements

Core Features

User requests a ride.
Find nearby drivers.
Driver accepts or rejects a ride.
Fare estimation and ETA.
Real-time driver tracking.
Start and end ride.
Payment processing.
Ride history.

Secondary Features

Ratings
Surge pricing
Cancellation
Notifications
Driver availability

Non-Functional Requirements

Requirement	Description
Availability	Very high
Scalability	Millions of users
Low Latency	Driver matching under 1 second
Real-time Updates	Continuous location streaming
Fault Tolerance	Ride state should not be lost
Consistency	Payments must be strongly consistent

High-Level Architecture

flowchart TD
    A["Mobile Apps<br/>Rider & Driver"] --> B[API Gateway]
    B --> C[Ride Service]
    B --> D[Driver Service]
    B --> E[Matching Service]
    B --> F[Pricing Service]
    B --> G[Payment Service]

    C --> H[Kafka / Message Queue]
    D --> H
    E --> H
    F --> H
    G --> H

    H --> I[Notification Service]
    H --> J[(Databases)]

Components

API Gateway

Responsibilities:

Authentication
Rate limiting
Routing
Request validation

Examples:

Kong
Nginx
Spring Cloud Gateway

Ride Service

Manages the ride lifecycle.

Ride states:

REQUESTED
DRIVER_ASSIGNED
DRIVER_ARRIVING
STARTED
COMPLETED
CANCELLED

Driver Service

Tracks:

Driver location
Driver availability
Driver profile

Driver states:

OFFLINE
AVAILABLE
BUSY

Matching Service

Responsibilities:

Find nearby drivers.
Rank them by distance.
Send ride requests.
First driver to accept wins.

Possible technologies:

Redis GEO
Elasticsearch
PostGIS

Location Service

Drivers publish their location every 3-5 seconds.

Driver App -> Location Service -> Redis GEO

Redis example:

GEOADD drivers 12.9716 77.5946 driver_123

Nearby search:

GEORADIUS drivers

Pricing Service

fare = base_fare
     + (distance * price_per_km)
     + (time * price_per_min)
     + surge_multiplier

Surge factor:

demand / supply

Payment Service

Responsibilities:

Authorization
Capture
Refunds

Notification Service

Handles:

Driver requests
Ride updates
Push notifications
SMS

Database Design

Rider

Rider
-----
id
name
phone
rating
created_at

Driver

Driver
------
id
name
car_details
rating
status

Ride

Ride
-----
id
rider_id
driver_id
pickup_location
drop_location
status
fare
start_time
end_time

Payment

Payment
-------
id
ride_id
amount
status
method
transaction_id

erDiagram
RIDER ||--o{ RIDE : books
DRIVER ||--o{ RIDE : serves
RIDE ||--|| PAYMENT : has

Ride Booking Flow

sequenceDiagram
participant Rider
participant RideService
participant Matching
participant Driver
participant Payment

Rider->>RideService: Request Ride
RideService->>Matching: RideRequested
Matching->>Driver: Ride Offer
Driver-->>Matching: Accept
Matching-->>RideService: Driver Assigned
RideService-->>Rider: Driver Details
Driver->>RideService: Start Ride
Driver->>RideService: End Ride
RideService->>Payment: Charge Fare

Steps:

POST /rides
Create ride with REQUESTED.
Publish RideRequested.
Match nearby drivers.
Driver accepts via POST /rides/{id}/accept.
Ride progresses to DRIVER_ASSIGNED, DRIVER_ARRIVING, STARTED, COMPLETED.
Trigger payment.

Low-Level Design

Ride Entity

class Ride {

    Long id;
    Long riderId;
    Long driverId;

    Location pickup;
    Location drop;

    RideStatus status;

    double fare;

    LocalDateTime startTime;
    LocalDateTime endTime;
}

RideStatus

enum RideStatus {

    REQUESTED,
    DRIVER_ASSIGNED,
    DRIVER_ARRIVING,
    STARTED,
    COMPLETED,
    CANCELLED
}

stateDiagram-v2
[*] --> REQUESTED
REQUESTED --> DRIVER_ASSIGNED
DRIVER_ASSIGNED --> DRIVER_ARRIVING
DRIVER_ARRIVING --> STARTED
STARTED --> COMPLETED
REQUESTED --> CANCELLED
DRIVER_ASSIGNED --> CANCELLED

RideService

class RideService {

    RideRepository rideRepository;

    MatchingService matchingService;

    public Ride requestRide(RideRequest request){

        Ride ride = createRide(request);

        matchingService.matchDriver(ride);

        return ride;
    }
}

MatchingService

class MatchingService {

    DriverRepository driverRepository;

    public Driver matchDriver(Location pickup){

        List<Driver> drivers =
            driverRepository.findNearestDrivers(pickup);

        return drivers.get(0);
    }
}

Scaling

Horizontal Scaling

Stateless Ride Service
Stateless Driver Service
Stateless Matching Service

Database Sharding

rides_1
rides_2
rides_3

Redis Cache

Driver locations
Active rides
Fare estimation

Handling Massive Location Updates

For one million drivers updating every three seconds:

Approximately 333K updates/second

Solution:

Kafka ingestion
Stream processing
Redis GEO indexing

Preventing Driver Acceptance Race Conditions

Use an atomic update:

UPDATE ride
SET driver_id = ?
WHERE id = ?
  AND driver_id IS NULL;

Only the first successful transaction assigns the driver.

Reliability

Retry
Circuit Breaker
Timeouts
Dead Letter Queue

Advanced Features

Driver batching

Offer rides to multiple nearby drivers simultaneously.

Surge Pricing

if demand > supply

surge = 1.5x

Demand Heatmaps

Predict high-demand zones.

Typical Technology Stack

Layer	Technology
Mobile	Android / iOS
API Gateway	Kong / Nginx
Backend	Java Spring Boot
Messaging	Kafka
Cache	Redis
Database	MySQL / Cassandra
Geo Index	Redis GEO
Observability	Prometheus + Grafana

Interview Focus Areas

Driver matching algorithms
Geospatial indexing
Real-time location streaming
Race condition handling
Scaling high-frequency location updates
Event-driven architecture

Key Takeaways

Separate responsibilities into dedicated microservices.
Use Redis GEO or geospatial databases for efficient driver lookup.
Stream location updates through Kafka before indexing.
Prevent multiple driver assignments with atomic database operations.
Keep payment processing strongly consistent while allowing eventual consistency elsewhere.