Motorcycle Ride-Hailing Platform

Problem

The operator needed to match passengers with nearby riders, let drivers bid on each ride, and keep live trip state consistent across passenger, driver, and admin screens while still being able to see how the platform behaves in production.

Constraints

• Drivers bid on each ride, so offers must reach the right passenger in real time
• Realtime events must work across more than one API instance
• Location data needs spatial queries, handled by PostGIS
• Operators need metrics, logs, and alerts, with a runbook for responders
• Passenger, driver, and admin surfaces share one API

Key Decisions

1. Driver bidding instead of a fixed fare

   Each ride's fare is negotiated, so drivers and passengers need to exchange offers while the request is still open.

   Drivers bid on each ride, and offers and trip updates are pushed over Socket.IO rather than polled.

   Trade-off: More realtime state and edge cases than a fixed-fare model, but both sides settle on a price they accept.
2. Socket.IO with a Redis adapter

   Offers and trip updates have to reach clients no matter which API instance holds their connection.

   Added the Socket.IO Redis adapter so events are shared across instances.

   Trade-off: Redis becomes a runtime dependency, but a second API instance works without sticky routing or code changes.
3. PostGIS through Drizzle with SQL migrations

   Matching riders and passengers depends on location, and the schema keeps changing as the product grows.

   Kept location queries in PostgreSQL with PostGIS, and managed the schema through Drizzle with 17 plain SQL migrations.

   Trade-off: Spatial SQL knowledge is required, but location logic runs in the database where it can be indexed.