When developing our dispatch service, one of the first things we decided to incorporate was multi-tenancy. Multi-tenancy, as seen in many SaaS services, means enabling multiple companies to use a service independently within a single architecture. Combined with the unique nature of dispatch operations, this feature has played an important role in our business expansion. Here, we explain the background behind its adoption and the architecture we designed.

Background

In many ride-hailing services overseas, individual drivers directly accept orders from users. In Japan, however, due to regulations, it is common for drivers affiliated with regional taxi or hire car operators to accept orders, rather than independent individual drivers.

Orders may be communicated directly to a dispatch app, or they may go through the operating company. The operating company then confirms dispatch availability, instructs drivers, and organizes the operation schedule. Some companies have their own dedicated dispatch systems.

The key decision point for multi-tenancy is how closely to integrate with each operating company. The goal is a multi-tenant setup capable of providing a dispatch system for each operating company individually. If the integration is kept loosely coupled and limited to matching individual drivers with users, multi-tenancy is not strictly necessary. However, to achieve a globally optimal matching that takes into account the entire operation schedule including advance reservations, it is necessary to go multi-tenant and integrate more deeply.

Ultimately, at NearMe, when considering the pre-booking airport shuttle ridesharing service, we decided to adopt multi-tenancy because we felt that closer collaboration with each operating company would allow for deeper optimization. That said, we have no intention of fully replacing existing dispatch systems; our development is focused on features for optimizing matching.

Architecture

Basic Structure

When designing the multi-tenant system, we looked to GitHub as a reference. The reason is that its data structure is general-purpose and its permission model is concise and easy to work with.

In GitHub, the resource called a “repository” is managed with permissions based on “organizations,” “members,” and “teams.” There is both personal use and organizational use; for the latter, a rough overview is as follows:

• One repository belongs to one organization
• One organization has multiple repositories
• One member can belong to multiple organizations
• Multiple members belong to one organization
• Each member can be designated as an owner of that organization or not
• Owners can perform any operation on the repositories owned by their organization
• Non-owner members have their permissions managed through teams
• One team belongs to one organization
• One organization has multiple teams
• Multiple members belong to each team
• Permissions for which repositories are granted to each team (e.g., read-only)

Mapping this to a dispatch service, a “repository” corresponds to a region-specific dispatch service. For example, “Haneda Airport Transfer,” “Narita Airport Transfer,” and “XX School Transfer” each correspond to individual repositories. The “organization” corresponds to each operating company. “Members” become the operations operators. Each member’s role for each service is then configured via teams.

Let’s look at how this data structure plays out in an actual workflow. For example, when an order comes in for “Haneda Airport Transfer,” the order is linked to the “Haneda Airport Transfer” service. The fare is determined based on that service’s settings. Whether the destination is within the service area is also judged based on the service’s settings. Subsequently, a member of the organization that owns “Haneda Airport Transfer” handles the order. Based on route information and the operation schedule, they determine whether dispatch is possible, and if so, assign a vehicle registered with the organization. The permissions for these operations are granted on a per-team basis.

Cross-Organization Collaboration

One thing that cannot be expressed by the basic structure above is a feature requiring cross-organization collaboration — for example, multiple operating companies participating in a single service to accept orders. Here we referenced a mechanism similar to AWS Cross-Account Resource Sharing. In our case, we implemented this by sharing a service with other organizations on a per-service basis. For example, to allow not only Organization A (which owns the “Haneda Airport Transfer” service) but also Organization B to accept orders for that service, we share the service with Organization B.

Closing Thoughts

At this point, we have built a basic multi-tenant dispatch system. Looking ahead, we want to explore not only cross-organization collaboration but also collaboration between individual services to achieve more sophisticated operations. We also want to incorporate a real-time mechanism for operators, something like Slack. Furthermore, we want to be prepared for a future where autonomous driving becomes commonplace.

Finally, NearMe is hiring engineers! This is a domain with enormous potential still to be unlocked. If you’re interested, we’d love to hear from you.

• Check out our careers page

Author: Kenji Hosoda