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.
- Part 1: Introduction, Requirements, Mobile and Web Applications
- Part 2: Backend Infrastructure and Service Architecture
- Part 3: Vendor Management and 3rd Party Customer Checkout
- Part 4: Delivery Supply & Demand and Forecasting with Machine Learning
- Part 5: Delivery Route Planning, ETAs, and Dynamic Pricing with Machine Learning
- Part 6: Delivery Driver Preferences, Management, Standings, and Rewards
- Part 7: Push-based Route Targeting and Precomputed Eligibility
- Part 8: Delivery Route Marketplace with On-Demand and Schedule-Ahead Routes and Deferred Resolution Route Matching
Part 1: Introduction, Requirements, Mobile and Web Applications
Contents:
- Introduction
- Prelude: Applying Multi-sided Market Design and Matching Theory
- User and Technical Requirements
- 3rd Party Vendors (Merchants & Taxi Companies)
- Customer Checkout
- Lifecycle of a Route
- Gig-Economy Drivers
- Driver Preferences
- Obtaining Work
- Schedule-Ahead Routes
- Preventing Bots
- On-Demand Routes
- Out of Scope
- User Requirements
- Technical Requirements
- Frontend Web and Mobile Applications
- E-Commerce Website or Mobile App
- Operations Portal
- Driver Mobile App
- End-to-End Flow
- Conclusion
Introduction
Envision a global transportation software platform where third-party vendors can rapidly deliver their goods or taxi services transport their customers, ranging from days in advance to as fast as same-hour – all without handling any of the logistical complexity themselves. Longer-lead deliveries are significantly easier to design for in that we have ample time to bundle deliveries across multiple stops, plan and optimize routes, acquire drivers, package the goods, and deliver the orders efficiently. They also come with lower costs for both the vendor and the customer.
On the other hand, ultra-low-lead deliveries – such as same-hour – are much more challenging due to the extremely short window for route optimization, driver acquisition, packaging, pickup, and delivery. Further, with such low lead times even the contents of a customer’s cart can significantly impact how quickly the order can be delivered. For example, certain products may only be available at certain local locations which the on-demand route will need to compensate for.
An independent gig-economy model for drivers, combined with real-time, on-demand delivery routes and dynamic pricing, works well here as spikes in demand are handled through surge pricing to ensure all delivery demand is fulfilled while drivers get flexibility and the potential for increased pay.
The scope of this problem space is huge and can be divided into three major phases: (1) the checkout experience, facilitated with the vendor; (2) the delivery planning process, where the platform schedules, optimizes, and matches delivery routes to drivers, and (3) the on-road experience, once a driver begins their assigned delivery route. Each of these phases could easily be the subject of an entire book and require 100s of engineers to implement at scale in a large enterprise. To keep the scope manageable, this series will focus only on the first two phases: the checkout and delivery planning processes. Elements of the on-the-road navigation systems are discussed in this article: Software Architecture - Mapping, Navigation, and ETA System.
Beyond this, there is the entire prep and fulfillment domain, which covers how goods are prepared for pick-up by delivery drivers. This process will vary significantly depending on the delivery type, vendor, and product – ranging from groceries to fast food to online retailers to brick and mortar and so on. In this series, we’ll design a marketplace for gig-economy drivers on a delivery platform, which vendors will integrate their customer checkout flows with.
In Part 1, we’ll begin by defining the user and technical requirements. We will then explore the web and mobile applications that support customers shopping, vendors managing their offerings, and drivers acquiring delivery routes. Finally, we’ll review the high-level end-to-end flow.
In Part 2, we’ll dive into the backend infrastructure and service architecture. In Parts 3-8, we’ll explore each of the domains, sub-systems, and services we will build. First, though, we’ll provide a prelude on Market Design and Matching Theory.
Prelude: Applying Multi-sided Market Design and Matching Theory
Research on Multi-Sided Marketplace Design and Matching Theory, including Deferred Resolution, offers valuable insights into how we can design software marketplaces. Our market needs to be “thick” enough, with sufficient order volume to keep drivers working and enough drivers to complete deliveries on time. It also needs to be simple to use, easy to reason about, and fair to ensure transparency. Our market needs to be fast enough to match routes to drivers in time for deliveries, while avoiding the risk of drivers finding work on other gig-economy platforms. However, the market also can’t be too fast, as drivers need enough time to review and sign-up for routes.
The following article dives deeper into this research around market design: The Economics of Multi-sided Market Design and Matching Theory.
Let’s apply the principles of Market Design and Matching Theory to our solution. Our platform will be a 3-sided marketplace:
- Traditional Marketplace (1st-party seller)
- 2-sided Marketplace (platform matches buyers and sellers)
- 3-sided Marketplace (platform matches buyers, sellers, and providers)
A common challenge with multi-sided marketplaces is the “chicken and egg” problem at launch, where ensuring a “thick” market of participants from each side of the marketplace is critical. Vendors won’t sign-up if there are not enough drivers to fulfill orders, whereas drivers won’t join if there is not enough volume to keep them working. We can solve this both from the demand-side and supply-side.
To solve the demand-side of the “chicken and egg” problem and ensure a thick market of orders for gig-economy drivers, we can start with onboarding vendors with existing high order volumes as an optional alternative to their current delivery providers. As order volumes increase, creating more gig-work opportunities, more drivers will naturally join the platform, creating a “flywheel” effect. As the supply of drivers grows, vendors will increasingly transition more orders to our delivery platform at lower cost.
To solve the supply-side of the “chicken and egg” problem and ensure a thick market of drivers to deliver orders, we can leverage two strategies depending on the lead-time (the time until expected delivery).
- For long-lead deliveries: We can integrate with professional delivery providers like UPS or FedEx to handle deliveries when we don’t have enough gig-economy drivers. This ensures vendors need not worry about orders being on time as we can leverage both gig-economy drivers and professional delivery providers. As more gig-economy drivers join the platform, the need to offload deliveries to external providers will diminish, though the integration can remain as backup for peak demand spiking beyond forecasts or unexpected supply shortages.
- For low-lead deliveries and taxi services: We can initially launch in a small, dense geographic area within a region and offer promotions of guaranteed minimum earnings to attract an initial set of drivers. As the driver pool grows, we can expand the region's geographic coverage.
While launching the platform and as we expand into new global regions, we can also incentivize drivers with referral bonuses for inviting friends and family, as well as first-time driver promotions to accelerate adoption. Similarly, we can offer new vendors promotions and discounted shipping rates to encourage them to join the platform and boost growth.
Now that we’ve covered the marketplace principles we’ll be designing for, let’s dive into the user and technical requirements.
User and Technical Requirements
3rd Party Vendors (Merchants & Taxi Companies)
The platform will support a wide range of products and vendors, including items fulfilled online, items sourced directly from physical retail stores, food and alcohol from restaurants or ghost kitchens, groceries, and even taxi services. Each type of delivery has its own unique constraints, so the platform must be configurable and extensible to accommodate them.
For example:
- Restaurants: Very short delivery time constraints, typically requiring direct routes.
- Groceries: Longer delivery windows of a couple hours, but may require the driver to physically shop and collect multiple items from the store.
- Alcohol: Age restrictions on drivers, varying per country.
- Schedule-ahead orders: Most other items scheduled ahead will be batched into multi-stop routes to improve efficiency and reduce costs.
- Taxis: Age, passenger-count, or pet restrictions on drivers
Customer Checkout
The platform will support three forms of customer checkout, applicable to a range of use cases:
- A shared traditional eCommerce website/app with multiple vendors - eBay, Walmart, or Amazon.
- A shared app with multiple vendors dedicated to gig-economy deliveries or taxi services - DoorDash, Instacart, Uber, or Lyft.
- Individual websites/apps built custom per vendor, integrated via APIs into our delivery platform - Shipt.
The solution we build can be tailored to support any of these checkout experiences. However, we will focus on the more complex use case, where each vendor has a custom-built website/app integrated into our delivery platform.
As customers checkout, they will see a dynamic list of available delivery windows, ranging from same-hour to a few days, with associated prices. Availability of delivery windows varies by region and time. For long-lead orders, delivery windows are determined using forecasts, augmented with real-time data. For low-lead orders and taxi services, the platform checks for enough available drivers near the pick-up location, with a cumulative likelihood of driver acceptance above a set confidence threshold.
Once the customer selects their delivery window and completes checkout, the vendor submits the order to the delivery platform. The platform then generates delivery routes and displays them to drivers looking for work.
The elastic gig-economy workforce ensures that spikes in demand can be handled without customer disruption, while keeping costs low for longer-lead schedule-ahead deliveries.
Lifecycle of a Delivery Route
The lead-time of an order will determine the type of route it is assigned to. For low-lead orders and taxi services, the order will immediately become an on-demand route pushed to individual drivers available nearby, one-at-a-time. Surge pricing will be applied as a lever for routes approaching delivery time without a driver assigned.
For long-lead orders, they will be batched into an optimal set of multi-order multi-stop routes. As more orders arrive, these routes may be re-optimized to achieve the optimal combination of routes for delivery efficiency, similar to the classic “traveling salesperson” computer science problem.
Routes with long-lead orders will first be targeted to specific drivers for promotions, rewards, or as an easy first-time route. If no driver accepts the route, it will become available to all drivers in the region who meet the route requirements. If still unassigned as the delivery start time approaches, the route will transition to an on-demand route, like a low-lead order, pushed to nearby drivers one-at-a-time with a limited time to accept. Throughout this process, route pricing is dynamically adjusted to optimize demand.
Gig-Economy Drivers
Driver Preferences
Drivers will set their route preferences explicitly through personalized settings, and these preferences will also be captured implicitly through Machine Learning analyzing their delivery history. This may include delivery-type (e.g. packages, groceries, food, taxi), time of day, day of week, etc. These preferences will be used to sort and filter the routes shown to them. Drivers can view their upcoming assigned routes, their history of completed routes, and their current standings at any time.
Obtaining Work
Drivers can obtain work from their onboarded geography through delivery routes in one of two modes: schedule-ahead and on-demand.
- Schedule-ahead: This unique gig-economy offering allows drivers to schedule work several days in advance, guaranteeing their earning potential. Drivers can view a list of available delivery routes and select the ones they are interested in. These selected routes are submitted to the platform, which asynchronously evaluates and assigns the routes to interested drivers. Some routes may be visible to all drivers, while others may be targeted to one or a subset of drivers as a promotion or reward.
- On-demand: These routes are pushed directly to nearby drivers who have enabled their on-demand mode.
Schedule-Ahead Routes
Schedule-ahead routes will often attract interest from multiple drivers, especially when tips are offered. Backend business logic will asynchronously determine which driver is awarded each route, considering factors such as driver standing, other routes they’re signed up for, and their qualifications for specific types of deliveries. Once assigned, the driver is notified and the route is added to their schedule.
Preventing Bots
We intentionally avoid the first-come-first-serve model, where the driver who selects a schedule-ahead route first is awarded the work. This model incentivizes the use of automated bots, which can acquire opportunities more quickly and continuously than a human, similar to bots used for purchasing limited product releases or concert tickets.
Queueing and raffles are simple options to curtail the speed and longevity incentives of bots, but instead we can leverage good market design and incentives to align behaviors with our goals. By implementing an asynchronous deferred resolution mechanism, we remove the advantages of speed and frequency, relying instead on driver standings, rewards, and other business logic to determine which driver is awarded a route.
This approach incentivizes the desired behaviors while ensuring a fair and transparent marketplace experience for drivers. With a slower-paced market, we also reduce the need for sub-second real-time updates, as data can be refreshed at a more manageable cadence.
On-Demand Routes
On-demand routes are real-time work opportunities pushed to drivers, with a limited time to accept or decline. Machine-learning models predict each available nearby driver’s likelihood-of-acceptance based on their history and stated preferences, ensuring low lead-time orders are sent to the drivers most likely to accept. If a route is not accepted within 30 seconds, it may be offered to other drivers.
Out of Scope
- Localization and translations.
- Disaster recovery and multi-region failover beyond multi-region isolation.
- The specific AI and Machine Learning models implemented for pricing, supply and demand forecasting, and implicit preference personalization.
- Optimizing for multiple delivery modes of transit (e.g. walking, biking, vans, rickshaws).
User Requirements
- Customers:
- Wide variety of delivery / pick-up options available, as quick as same-hour up to several days, paired with reasonable prices.
- Delivery / pick-up windows are accurate and delivered upon reliably.
- Vendors (Merchants & Taxi Companies):
- Ultra-low latency retrieval of available delivery / pick-up windows to maximize conversion rate in checkout flows.
- Real-time supply and demand monitoring to provide accurate delivery window / pick-up availability to customers.
- Dynamic delivery window calculation for ultra-low-lead orders considering cart contents and available stock.
- Drivers:
- Support schedule-ahead (pull) and real-time on-demand (push) acquisition of work in delivery routes.
- Support routes with multiple orders and stops; update routes as new orders come in.
- Deferred resolution for schedule-ahead routes; no first-come-first-serve incentive for bots; drivers have time to opt-into routes without speed-to-accept pressure.
- Provide transparency to drivers of which routes will be more popular; include feedback loops to update which routes are most popular for future offerings.
- Support promoted routes exclusively pushed to a driver who is performing well which fits their preferences; include feedback loops to update driver preferences (implicit + explicit).
- Dynamic pricing relative to delivery demand.
Technical Requirements
- Support up to 100-million packages, 20-million routes, and 10-million drivers at any given time worldwide with multi-region isolation.
- Out of scope: Multi-region failover or active-active multi-region design.
- Sub-100ms response times for customers checking out.
- High availability (99.99%) of the platform; viewing/obtaining/planning functionality is decoupled and isolated from on-the-road delivery functionality so failure in one does not cause the other to fail.
Frontend Web and Mobile Applications
We have three user-facing applications to consider: (1) vendor websites and mobile apps for customers to shop and checkout, (2) a vendor and operations admin interface for managing configuration and overrides, and (3) a delivery driver mobile app for viewing and accepting gig-economy delivery routes.
3rd Party Vendor E-Commerce Websites and Mobile Apps
Vendors may list their products on a shared website/app alongside other vendors, or they have their own website and mobile app integrated into our delivery platform. In either case, the customer-facing interface will be implemented as one of the following:
- A traditional backend-rendered website
- A single-page-application (SPA) with asynchronous backend calls
- A hybrid mobile app (cross-platform)
- Native Android (Java/Kotlin) and iOS (Objective-C/Swift) mobile apps
Each e-commerce website or app has three primary call patterns into our delivery platform: Checkout: Query available delivery windows and prices, providing the cart contents, pick-up address(es), and delivery address. Order Submission: Submit the order to the delivery platform after checkout and payment. Post-Checkout: View the order’s delivery status and ETA.
To support these use-cases, the backend APIs – especially those used during checkout – must be low-latency (<100ms) to optimize conversion rates for vendors.
Operations Portal for Vendors and Operations
As vendors onboard to the platform, they will need a way to configure and revise their metadata and settings. Similarly, administrators and operations managers of the delivery platform will require a way to modify configurations, set up new regions, and set ad-hoc overrides. To meet these requirements, we will build a Delivery Operations Portal. Since this portal serves a smaller set of users and the users are already on our platform, SEO and latency requirements are less stringent than those for eCommerce customer checkouts. Preferring simplicity and low-cost for the Operations Portal, we will build a React single-page-application hosted on Amazon S3, costing not much more than pennies per month.
Driver Mobile App
The primary interface for the delivery platform will be the driver-facing app and associated platform APIs to support delivery drivers viewing and acquiring new gig-economy delivery routes to work. This mobile app will have significant traffic and require reasonably low latency (<1s) for a smooth user-experience. Given that drivers will often be in transit or away from home, a mobile application is the most practical solution. As the primary interface, the app will need a polished UI. It will also require hardware-related functionality, such as GPS and potentially photo uploads for identity verification. Therefore, we will build native mobile apps for Android (Kotlin) and iOS (Swift).
While native mobile apps offer benefits in polish and better hardware integration (e.g. GPS, camera, Bluetooth), they also come with the downside of additional development time building two applications (Android and iOS) and highly restrictive release cadences. To balance these trade-offs, we will design the mobile app to be “thin” – with most business logic pushed to backend services accessed through a shared backend presentation and data-aggregation layer. This approach reduces redundant logic across the apps and minimizes the frequency of app deployments, allowing for faster releases.
In addition to keeping the two native mobile apps “thin” and lightweight, for performance and to preserve battery life we will: (1) minimize the data payload across the network, (2) minimize the number of network round trips across the network, and (3) minimize the total network requests across the network through the backend data-aggregation layer. The driver mobile app will long-poll the backend every 30-60 seconds while it is open to get the latest schedule-ahead routes. The refresh rate is sufficient as we are leveraging Deferred Resolution so drivers accepting more quickly are given no advantage. If we change this mechanism and reduce the polling to increase the refresh-rate below say 10 seconds, we would move this to Web Sockets or another technology for real time data refreshes, but currently that is more expensive and complex than needed for our use case. For drivers in on-demand mode, on-demand routes will be pushed directly to them through native push events.
End-to-End Flow
With the requirements and mobile/web applications outlined, let’s now step back and examine the high-level end-to-end customer flows and associated systems. Each of the systems and functions generalized in this diagram will be detailed in greater detail in the following parts of this series.
Conclusion
Here, we’ve covered the user and technical requirements for each of our three user groups: third-party vendors, customers, and gig-economy delivery drivers. We’ve also reviewed the end-to-end flow of the platform. Next, let’s dive into the backend infrastructure and service architecture we need.