Introduction

Order processing in a dispatch service is similar to order processing in e-commerce. In e-commerce, users search for products, add items to a cart, and place an order. The order can be accepted if inventory is available. In other cases, users may be notified later that inventory has been secured or that the item is out of stock. After that, shipping is arranged and an estimated delivery date is shared.

In a dispatch service, the equivalent of a product is transportation from an origin to a destination. The equivalent of inventory reservation is securing driver availability. In some cases, dispatch confirmation can take time. After that, dispatch arrangements are made and details such as pickup time are communicated.

In this article, I explain order processing in NearMe’s ride-sharing service. Our service accumulates advance reservations and, whenever a new order arrives, calculates an optimal ride-sharing combination so that dispatch confirmation can be performed incrementally. Let’s look at the patterns that appear in this kind of ride-sharing operation.

Basic Order Processing

The main flow in dispatch order processing is: order request (Apply) -> dispatch decision (Accept/Reject) -> completion (Complete). However, an order may also be canceled (Cancel) before dispatch is finalized. The diagram below illustrates this flow.

There are several ways to make the dispatch decision. One is for an operator to view the full operating schedule and reserve a driver manually. In that case, there is a delay between Apply and Accept/Reject, for example, “we will respond within 24 hours.” Another is for drivers to decide directly. Especially in real-time dispatch, a new order triggers a notification to nearby drivers, and the decision is made there. Other approaches are also possible, such as automated decision-making based on various signals, or speculative acceptance when the acceptance rate is known to be high.

Up to this point, the flow is relatively simple.

State Transitions with Ride Sharing

Building on the basic flow above, this section explains state transitions for each order and for a Trip that groups multiple orders when many orders arrive.

First, the next diagram shows how multiple orders are combined and confirmed as ride sharing progresses.

The steps are as follows.

1. Start from an empty state.
2. When order A arrives (Apply A), temporary Trip 1 is created.
3. When order B arrives (Apply B), it is grouped with order A under temporary Trip 1.
4. Confirm dispatch for order A (Accept A). Trip 1 remains temporary because order B is not yet accepted.
5. Confirm dispatch for order B (Accept B). Since all orders under Trip 1 are now accepted, Trip 1 becomes effectively finalized.
6. Alternatively, from step 3, we can accept at the trip level (Accept Trip1) and confirm orders A and B at the same time.
7. Order C arrives (Apply C), and a three-order shared ride is formed. Because order C is not yet accepted, Trip 1 returns to a temporary state.

This shows that orders can accumulate before final confirmation while ride-sharing optimization runs incrementally.

Next, let’s look at a pattern where an order is reassigned to a different trip.

1. Orders A and B are currently grouped for ride sharing before dispatch confirmation.
2. When order D arrives, two trips appear, and order B is regrouped with order D. In this situation, the pair B+D is more efficient than A+B, and the three-order combination A+B+D is not feasible.
3. If order D is rejected (Reject D), order B is grouped back with order A, and Trip 2 disappears.

You can see dynamic interactions among pending orders before dispatch is confirmed.

On the other hand, if operations are handled more conservatively by manually reserving schedules, we can impose a rule that “accepted orders are never moved to another trip” to reduce operational complexity. In that case, behavior looks like this.

1. Order A is accepted alone, while orders B and D are accepted together as a shared ride.
2. Under the rule “do not move accepted orders to another trip,” if order D is canceled, orders A and B stay in separate trips.

In the previous case, a rejection/cancellation collapsed the schedule into one trip, but here it remains as two trips. This rule can be configured, representing a trade-off between operational simplicity and dispatch efficiency.

Time Finalization

In advance-booking ride-sharing dispatch, the flow Apply -> Accept/Reject -> Complete includes an additional step after acceptance: time finalization (Finalized). Allowing a pickup time window makes ride sharing easier to form (reference), but a wider window can make planning harder for users. So at a certain point, for example one day before pickup, we finalize the pickup time or narrow the window.

Now let’s look at this flow with ride sharing in mind.

1. Orders A and B are grouped as a shared ride before dispatch confirmation.
2. Finalize time for Trip 1 (Finalize Trip1). Time finalization is performed per trip, not per order. At this point, each order’s pickup time window is narrowed. If pickup times were fixed completely, additional ride sharing would almost never occur (only adjacent requests or exactly identical routes could be merged), so in practice we keep a small window. Users are notified of the finalized pickup time. Also, even if additional ride sharing happens later, pickup times are not moved earlier.
3. Order C arrives and is grouped with orders A and B.
4. Finalize time for Trip 1 again (Finalize Trip1). At this time, order C receives its pickup-time notification. If pickup times for orders A or B changed, those users are also notified of their updated times.
5. If order B is canceled, operation becomes slightly less efficient, but pickup times remain unchanged and orders A and C stay in Trip 1.

This shows that additional ride sharing can still occur after time finalization, under tighter time constraints.

Handing an Order to Another Trip

Finally, let’s look at Skip, a process that removes an order from its current trip and hands it to another one. This is implemented by adding a constraint that prevents a specific order from being assigned to a specific trip (reference). The idea is that even if a new shared ride is found, scheduling constraints may make the current trip infeasible, so the order should be handed off to another trip.

1. Orders A and B are accepted in different trips, and an additional order D arrives and is grouped with order B.
2. By detaching order D from its current Trip 2 (Skip D), it can be grouped with order A.
3. If order D is further detached from its current Trip 1 (Skip D), it cannot rejoin Trip 2 because that trip was already excluded, so it becomes an independent trip.

This illustrates incremental ride-sharing processing under more complex constraints.

Closing

We have reviewed various state transitions in order processing for an advance-booking ride-sharing dispatch service. Through operations such as Apply, Accept/Reject, Cancel, Finalize, and Skip, we saw that not only individual order states but also interactions between orders produce diverse patterns. We also saw how constraints can evolve in fine detail during processing, such as narrowing pickup-time windows or disallowing assignment to specific trips. I hope this helps convey how carefully these patterns are managed to deliver the service.

As a final note, NearMe is hiring engineers. This domain still has a lot of untapped potential. If you are interested, please apply below.

• Careers

Author: Kenji Hosoda