Designing a Trip Matching Engine in Rails

AINORY was a social taxi carpool matching platform where drivers post trip offers and riders join them in real time. The matching engine was the heart of the system — and getting it wrong meant lost trips and angry users.

The Problem Space

A match event involves multiple concurrent actors: a driver broadcasting an available trip, multiple riders requesting to join simultaneously, and the system confirming one rider and notifying others. This is a classic optimistic concurrency problem.

Solution: Serialized Matching with Advisory Locks

We used PostgreSQL advisory locks to serialize matching per trip, ensuring only one join request is processed at a time without blocking unrelated trips. The lock is scoped to the trip ID, so parallel requests for different trips proceed independently.

Real-Time Confirmations

Once a match is confirmed, ActionCable broadcasts the result to all subscribers of that trip's channel. Riders see instant "Seat Taken" or "You're matched!" notifications without polling.

Spatial Queries

We used PostGIS extensions on PostgreSQL to query nearby trip offers within a configurable radius, avoiding full-table scans as the dataset grew.

Outcome

Matching conflicts reduced to zero after advisory lock implementation. Average match confirmation time under 200ms end-to-end. System handled peak-hour load without degradation.