| Cyclomatic Complexity :👈 | 👉:Service Per Subdomain Pattern |
Building a Taxi Booking Application |
To build a reliable taxi-booking application like Uber or Ola, GPS alone is not enough. GPS provides raw geographic coordinates (latitude and longitude), which are highly inaccurate indoors, suffer from signal "drift," and lack human-readable context.
To turn raw coordinates into a functional booking experience, you need a complete Location Stack consisting of the following technical components:
1. Reverse Geocoding API (Turning Coordinates into Addresses)
GPS gives you 17.3616, 78.4747. Your user needs to see "Charminar, Hyderabad".
What it does: Converts raw lat/long coordinates into a readable address, street name, or building name for the pickup field.
Top Options: Google Places API (Reverse Geocoding), Mapbox Geocoding API, Radar, or OpenStreetMap (Nominatim) for an open-source alternative.
2. Places Autocomplete & Search API
Users rarely wait for GPS to lock onto their exact location; they usually start typing their pickup point or destination.
What it does: Provides type-ahead predictions, matches partial text to real-world locations, and corrects spelling errors.
Top Options: Google Places Autocomplete, Mapbox Search, or TomTom Search API.
3. Fused Location Providers (Hybrid Positioning)
Relying solely on GPS hardware drains the phone's battery rapidly and fails entirely inside high-rise buildings, tunnels, or metros.
What it does: Combines hardware inputs—Cell Tower IDs, Wi-Fi Networks, Bluetooth Beacons, and Accelerometers—with GPS to determine location instantly, even indoors or under heavy tree cover.
How to use it:
- For Android: Google Play Services Location APIs (FusedLocationProviderClient)
- For iOS: CoreLocation Framework
4. Snap-to-Road & Routing Engines
Raw GPS coordinates bounce around. If a user is standing on the sidewalk, the GPS might inaccurately place them inside a building or on an adjacent highway.
What it does:
- Snap-to-Road: Aligns the user's messy GPS coordinates to the nearest navigable road or designated passenger pickup pin.
- Distance Matrix: Calculates the exact travel distance and Estimated Time of Arrival (ETA) between the available taxis and the customer.
Top Options: Google Maps Roads API, OSRM (Open Source Routing Machine), Valhalla, or Mapbox Directions.
5. Geo-fencing & Geo-hashing (Backend Architecture)
To show a list of nearby drivers to a customer, your backend cannot query millions of driver coordinates globally every second. It will crash.
What it does: Divides the earth into a grid (cells). When a customer opens the app, the backend only searches for active drivers inside the customer's specific grid cell and adjacent cells.
How to use it: Implement Redis Geo commands (GEOSEARCH), PostgreSQL with PostGIS extensions, or libraries using H3 (Uber’s hexagonal hierarchical spatial index) or Geohash.
6. Real-Time WebSockets / Pub-Sub Architecture
A taxi app requires instant updates. As drivers move, their positions must update smoothly on the customer's screen without refreshing the page.
What it does: Maintains a constant, lightweight, open connection between drivers, servers, and customers to stream live coordinate updates every 1 to 3 seconds.
Top Options: WebSockets, Socket.io, gRPC, MQTT (highly optimized for mobile networks), or managed services like Pusher and AWS AppSync.
Summary Table: Tech Stack Overview
| Feature Needed | Tech/API Tool | Purpose |
|---|---|---|
| Address Generation | Google/Mapbox Geocoding | Converts GPS dots to real street addresses. |
| Search/Type-ahead | Places Autocomplete | Allows manual address search with text prediction. |
| Indoor/Fast Lock | Fused Location (iOS/Android) | Combines Wi-Fi + Cell towers with GPS for battery efficiency. |
| Finding Nearby Cars | Redis Geo / Uber H3 | Indexes driver locations so matching takes milliseconds. |
| Live Map Movement | WebSockets / MQTT | Streams moving vehicle icons across the user's screen. |
For a taxi booking app, GPS alone is not enough. A production-grade taxi app typically needs the following location and mapping components:
1. User Location Detection
Purpose: Get the customer's current position.
Required:
- GPS (primary source)
- Wi-Fi positioning (indoors)
- Cell tower triangulation (fallback)
-
Mobile OS Location Services
- Android Fused Location Provider
- iOS Core Location
Data obtained:
{
"latitude": 17.3850,
"longitude": 78.4867,
"accuracy": 15
}
2. Reverse Geocoding
Purpose: Convert coordinates into a human-readable address.
Example:
17.3850, 78.4867 ↓ Banjara Hills, Hyderabad, Telangana
Providers:
- Google Maps Geocoding API
- Mapbox Geocoding API
- HERE Maps
- OpenStreetMap Nominatim
3. Place Search / Autocomplete
Purpose: Let users search pickup and destination locations.
Example:
- Type "Rajiv"
-
Suggestions:
- Rajiv Gandhi International Airport
- Rajiv Chowk Metro
Providers:
- Google Places API
- Mapbox Search
- HERE Places
4. Interactive Maps
Purpose: Show pickup point and route.
Features:
- Current position marker
- Destination marker
- Zoom/Pan
- Driver icon movement
Options:
- Google Maps SDK
- Mapbox SDK
- HERE SDK
5. Route Calculation
Purpose: Find route between pickup and destination.
Returns:
- Distance
- Duration
- Turn-by-turn path
Example:
{
"distance": "12.5 km",
"duration": "28 min"
}
APIs:
- Google Directions API
- Mapbox Directions API
- OSRM (Open Source)
6. Distance Matrix
Purpose: Find nearest drivers and ETA.
Example:
Driver A → 2 mins Driver B → 5 mins Driver C → 7 mins
APIs:
- Google Distance Matrix
- Mapbox Matrix
7. Real-Time Driver Tracking
Purpose: Continuously update driver position.
Common technologies:
- WebSocket
- SignalR (.NET)
- Firebase Realtime Database
- MQTT
Driver sends location every:
2-5 seconds
8. Geofencing
Purpose: Detect when a driver enters or leaves an area.
Uses:
- Airport pickup zones
- City boundaries
- Surge pricing zones
9. Location Permissions
You need to handle:
Customer
- Allow location access
- Allow background location (optional)
Driver
- Background location mandatory
- Always-on tracking during duty
10. ETA Calculation
Not just GPS coordinates.
Factors:
- Current traffic
- Road restrictions
- Historical traffic trends
- Driver speed
Used for:
Driver arriving in 3 mins Trip duration 25 mins
11. Ride Matching Engine
After getting locations:
Customer Location ↓ Nearby Drivers ↓ Calculate distance ↓ Choose nearest available driver ↓ Send ride request
Backend may use:
- PostgreSQL + PostGIS
- Redis Geo
- MongoDB Geospatial Indexes
12. Recommended Architecture
For a .NET/C# taxi application, a popular stack is:
Frontend:
.NET MAUI / Flutter
Backend:
ASP.NET Core Web API
Realtime:
SignalR
Database:
PostgreSQL + PostGIS
Maps:
Google Maps Platform
or
Mapbox
Push Notifications:
Firebase Cloud Messaging
Minimum MVP
If you're building the first version, implement:
- GPS location
- Reverse geocoding
- Place autocomplete
- Route calculation
- Real-time driver tracking (SignalR)
- Nearby driver search
- ETA calculation
These seven features will cover about 90% of the location functionality needed for an Uber/Ola-style taxi booking app
Architecture Diagram
Mobile Applications
1. Customer App
Features:
- Register/Login
- Current Location
- Search Destination
- Fare Estimate
- Book Ride
- Live Driver Tracking
- Ride History
- Payments
- Ratings & Reviews
Technology:
- Android -> Kotlin
- iOS -> Swift
2. Driver App
Features:
- Driver Registration
- Vehicle Details
- Online/Offline Mode
- Accept/Reject Trips
- Navigation
- Live GPS Sharing
- Earnings Dashboard
- Trip History
Technology:
- Android -> Kotlin
- iOS -> Swift
Most ride companies focus mainly on Android for drivers.
Backend Services
1. API Gateway
Responsible for:
- Authentication
- Authorization
- Request Routing
- Rate Limiting
- API Versioning
Technology:
- ASP.NET Core
- YARP Reverse Proxy
2. User Service
Stores:
- Customers
- Drivers
- Vehicles
- Documents
Tables:
- Users
- Drivers
- Vehicles
- DriverDocuments
3. Booking Service
Responsible for:
- Create Ride
- Cancel Ride
- Trip Status
- Assign Driver
- Trip Lifecycle
Ride States:
- Requested
- Accepted
- DriverArriving
- Started
- Completed
- Cancelled
4. Location Service
Most important service.
Stores:
- Latitude
- Longitude
- Heading
- Speed
- Last Updated Time
Functions:
- Nearby Drivers
- Distance Calculation
- Geofence Detection
- Tracking
- ETA
5. Payment Service
Responsible:
- Fare Calculation
- Promos
- Wallet
- Payment Processing
- Settlement
External:
- RazorPay
- Stripe
- PayTM
- PhonePe
6. Notification Service
Responsible:
- Ride Request
- Driver Arrived
- Trip Started
- Payment Completed
Providers:
- Firebase Cloud Messaging
- Apple Push Notification Service
7. Realtime Service
Use:
- ASP.NET Core SignalR
For:
- Driver Location Updates
- Live Tracking
- Ride Status Updates
- Messaging
Database Design
PostgreSQL + PostGIS
For geo-spatial searches.
Users
UserId
Name
Phone
Email
Role
Drivers
DriverId
VehicleId
Status
CurrentLocation
Vehicles
VehicleId
Type
Number
Model
Bookings
BookingId
CustomerId
DriverId
PickupLocation
DropLocation
Status
CreatedDate
Payments
PaymentId
BookingId
Amount
Status
Redis
Use Redis heavily.
Purpose:
- Online Drivers
- Driver Location Cache
- OTP Storage
- Ride Requests
- Session Data
Example:
driver:1001
lat:17.4512
lng:78.3812
online:true
Finding Nearby Drivers
Instead of:
foreach(driver)
{
CalculateDistance();
} Use PostGIS:
ST_DWithin()
Example:
SELECT * FROM Drivers
WHERE ST_DWithin(location,customer_location,5000);
Returns drivers within 5 km.
Real-Time Tracking Flow
Driver Phone
|
| Every 3 sec
|
v
SignalR Hub
|
v
Location Service
|
v
Redis
|
v
Customer App
Driver sends:
{
"lat": 17.412,
"lng": 78.456,
"speed": 43
}
Cloud Infrastructure
For production:
- Azure App Service
- Azure Kubernetes Service
- Azure PostgreSQL
- Azure Redis Cache
- Azure Storage
- Azure Service Bus
- Application Insights
Alternative AWS:
- EKS
- RDS PostgreSQL
- ElasticCache Redis
- S3
- SNS
Additional Services Needed for Ola Scale
Trip Pricing Service
- Base Fare
- Distance Fare
- Time Fare
- Surge Pricing
Driver Matching Engine
- Nearest Driver
- Vehicle Type
- Driver Rating
- Ride Acceptance Rate
Analytics Service
- Daily Trips
- Revenue
- Peak Hours
- Heat Maps
- Driver Utilization
Fraud Detection
- Fake GPS
- Multiple Accounts
- Payment Abuse
| Cyclomatic Complexity :👈 | 👉:Service Per Subdomain Pattern |
Comments and Discussion