Introduction

We recently released a timetable feature for our airport shared-ride service to better fill empty seats. We had this idea for a long time, and finally brought it to production. In this post, I will explain the feature and how we built the system.

About the Timetable

At NearMe, we have built a service where users share taxi or shuttle vehicles. (Although both are called “shared rides,” this is different from the “ridesharing” model often discussed in the context of driver shortages, where private drivers are matched with passengers.)

We have especially focused on features that improve operational efficiency for advance-booking scenarios such as airport transfers. For example, we optimized user-to-user matching (reference, reference), and also optimized vehicle-to-operation matching to create denser operation plans (reference).

We also implemented a recommendation feature that suggests rides with slightly shifted times to fill seats in already-scheduled operations (see below).

Recommendation display. The top is the user’s requested ride. The bottom is an already-scheduled matching ride, offered at a lower price because the timing differs from the original request.

To fill those seats even further, we developed the timetable feature. It shows a list of existing scheduled operations so users can choose a matching ride even if the time or location is slightly different from what they originally wanted.

Users can enter preferred locations to narrow down matching operations:

Filtering operations by entering locations on the timetable.

After selecting an operation, users can also view the area where matching is possible (note that dispatch may still fail in some cases even within that area).

Displaying the area where matching is possible for a selected operation.

One use case is spending some time at the airport, taking a shuttle to a station on the way, and then taking a taxi for the final leg.

This feature is especially effective for last-minute bookings. In general, arranging a vehicle from scratch becomes harder as departure time gets closer, while adding a passenger to an already-scheduled vehicle is easier operationally and cheaper.

System Design

The concept is inspired by bus timetables, but the novel point is applying it to more dynamic taxi and shuttle operations.

The timetable list itself is straightforward: we filter operations by time and display them after masking location details.

The difficult part is filtering operations that may match when users enter preferred locations. Another challenge is when users select an operation from the list without entering a preferred location: we need to display how far the matching area extends while intentionally blurring exact position data.

In the current implementation, we calculate matchable areas as polygons using simple formulas, and merge polygons when there are multiple waypoints. (Because this is an approximation, there is still room for improvement.)

To blur locations, we also lower polygon resolution using h3.

One design trade-off was whether to store the computed results or calculate them on demand. Persisting them would simplify search but make consistency management more complex. On-demand calculation, on the other hand, can increase system load during searches.

We ultimately chose on-demand processing. With filtering and caching, we judged the response speed to be acceptable.

Still, we found that implementing the algorithm in JavaScript took tens to around a hundred milliseconds per operation. Processing dozens of operations in a single search could therefore take several seconds in the worst case. Running that in our existing Node.js service (especially given its single-threaded nature) would have too much impact on existing workloads.

So we split this logic into a separate service and implemented it in Rust. As a result, we confirmed about a 10x speedup. As a side benefit, image size and memory footprint were also much smaller, which lowered the operational barrier to adding a new service.

For the production implementation, we wrote unit tests and also built an interactive API validation tool using Streamlit (see below). This tool helped us find several issues that were difficult to catch with unit tests alone.

Future Outlook

Right now, this feature is only shown on the airport transfer site, but we want to expand it to many more usage scenarios. For example, because we can display matching operation lists for registered locations, we would like to place QR codes at hotel counters and similar locations so users can quickly find available seats. We also expect this to improve matching opportunities for shuttles in regions with relatively low user density.

Finally, NearMe is hiring engineers. This is a domain with a lot of untapped potential, and we would love to hear from you if you are interested.

• Careers

Author: Kenji Hosoda