The sharing economy has introduced a new wave of online marketplace apps and business models, where consumers and sellers are matched across a unique differentiated set of product inventory. This contrasts with traditional e-commerce platforms, where inventory is standardized and sellers are few. Online multi-sided marketplaces range from Uber and Lyft in gig-economy transportation of people with unique routes to DoorDash and Postmates in restaurant delivery with unique orders, Instacart and GoPuff in grocery delivery with unique pick-up and drop-off locations, TaskRabbit and Amazon Mechanical Turk with unique ad-hoc jobs, Turo and Boatsetter for individual car and boat rentals, Airbnb with unique one-of-a-kind accommodations, and Rover for dog care.

Each of these businesses has successfully created a marketplace that matches customers with a wide variety of sellers offering differentiated products or services, rather than standardized items. This creates a more complex system than traditional retail as it presents a complex optimization problem where we must balance the multiple needs across a diverse set of users - times/dates, locations, qualifications / features / amenities, availability, regional regulations, and so forth. Additionally, the rules and functioning of the marketplace need to be considered carefully to prevent gaming and ensure a fair and transparent marketplace for all parties.

In this 8-part e-book, we will design a multi-sided online marketplace encompassing multiple domains, subsystems, and applications, with principles which can be applied to a wide variety of marketplace and gig-economy use cases from taxi services (e.g. Uber, Lyft), to restaurant delivery (e.g. DoorDash, Postmates), to third-party deliveries (e.g. Instacart, Shipt, Convoy). We’ll focus on a complex three-sided marketplace use-case involving three distinct sets of users: customers making purchases, third-party vendors, and gig-economy drivers. By the end we will have designed a global transportation platform with multi-sided marketplace where (i) consumers can shop through a variety of vendors (3rd-party merchants or taxi services), (ii) have their goods or themselves delivered quickly – as quick as same-hour, (iii) by gig-economy drivers, (iv) either scheduled-ahead or on-demand, (v) all without merchants or taxi companies managing any of the logistical complexity.

We must balance: speed, low-cost, and accurate-ETA’s for customers; consistent, highly-available taxi & delivery services for third-party merchants and taxi companies; and fairness, transparency, and consistency for gig-economy drivers. The platform will support a wide range of transport speeds starting as quick as same-hour with low latency APIs to optimize the checkout flow for maximum conversion. We will support multiple pick-up and drop-off locations, given products and customers will be distributed. Finally, we will support multiple mechanisms for gig-economy drivers to obtain work, either scheduling work ahead to guarantee sufficient working hours or working on-demand with maximal flexibility, obtaining work in real time.

  1. Part 1: Introduction, Requirements, Mobile and Web Applications
  2. Part 2: Backend Infrastructure and Service Architecture
  3. Part 3: Vendor Management and 3rd Party Customer Shopping & Checkout
  4. Part 4: Transport Supply & Demand Management and Forecasting with Machine Learning
  5. Part 5: Route Planning, ETAs, and Dynamic Pricing with Machine Learning
  6. Part 6: Driver Onboarding, Preferences, Standings, Rewards, and Payments
  7. Part 7: Driver-Route Targeting, Pushed On-Demand Routes, and Precomputed Eligibility
  8. Part 8: Gig-Economy Route Marketplace for Schedule-Ahead Routes with Deferred Route Matching
Software Architecture Series:

Part 7: Driver-Route Targeting, Pushed On-Demand Routes, and Precomputed Eligibility

Contents:

  1. Introduction
  2. Driver-Route Precomputed Eligibility
    1. Program-Wide Eligibility
    2. Order-Type Eligibility
    3. Route-Specific Eligibility
  3. Forecasted Route Popularity
  4. Driver-Route Targeting
    1. Rewards of Schedule-Ahead Routes
    2. Promotions for Hard-to-Fill Schedule-Ahead Routes
    3. On-Demand Routes
  5. Driver-Pushed On-Demand Routes and Notifications
  6. Conclusion

Introduction

In Part 1, we envisioned a global transportation software platform enabling third-party vendors to rapidly transport goods to customers – or customers themselves – within an hour, covering requirements, web/mobile apps, and overall flows. In Part 2, we explored the backend infrastructure and service architecture. In Parts 3-8, we are going through the multitude of domains, subsystems, and services we will require. In Parts 7 and 8 we discuss the Route Marketplace domain - split into two parts given the large scope of the domain. Here in Part 7, we detail how we determine driver-route eligibility and dive into the Driver Route Targeting subsystem.

Driver-Route Precomputed Eligibility

Through the course of this book we’ve discussed two modes in which drivers can acquire routes to work - schedule-ahead and on-demand. In both cases, before we ever can share a route with a driver we must ensure that driver is indeed eligible to work the route. This is where the Driver-Route Eligibility Precompute Service comes in - to precompute routes and drivers in each region to determine eligibility ahead-of-time. There are a variety of reasons a driver may be ineligible to work a route: program-wide driver eligibility, order-type eligibility, and route-specific eligibility.

Program-Wide Eligibility

Drivers may or may not be eligible to work on the platform at all. Reasons they may be ineligible could include:

  1. Work authorization is expiring Total hours worked that shift, day, week, month, or year will exceed local legal limits Driver’s overall standing is too low Driver’s vehicle insurance is expiring or vehicle mileage will exceed local legal limits

Order-Type Eligibility

Drivers may only be eligible for specific order-types. Reasons they may be ineligible for certain order-types could include:

  1. Not of age to deliver age-restricted goods (e.g. alcohol in the US)
  2. Vehicle is not well suited for taxi services
  3. Driver’s standing for the specific order-type is too low

Route-Specific Eligibility

Drivers may not be eligible for the specific route, such as:

  1. Driver has a preceding or following route already accepted which overlaps
  2. Driver has a preceding or following route already accepted without enough time in between routes to travel from the end of the first route to the start of the second route
  3. Driver cannot get to the route start by route start time from their current location

Iterating through each eligibility check is time consuming and doing so within the driver user flow each time the Driver App routes page is reloaded is both inefficient and a slow inadequate experience for drivers. Rather than compute this eligibility for every route every time a driver loads the Driver App and reviews available routes, we precompute this ahead of time to reduce latency for drivers and reduce computation cycles our Driver Vending Service must handle.

The remainder of this chapter is available by purchasing the e-book.

Sign up to the mailing list to read additional free chapters of my book on Software Engineering, Architecture, and Delivery Book