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:

• Software Architecture - Mapping, Navigation, and ETA System
• Software Architecture - Metrics and Alarms Monitoring System
• Software Architecture - Payments System
• Software Architecture - Hotel Reservation Booking System
• Software Architecture - Translations Service & Clients

Part 3: Vendor Management and 3rd Party Customer Shopping & Checkout

Contents:

1. Introduction
2. Vendor
3. 3rd Party Customer, Shopping, and Checkout
   1. Retrieving Delivery Windows and Pick-Up Time Availability
      1. Long-Lead Orders
      2. Low-Lead Orders
      3. ML-Forecasted Driver Acceptance Likelihood
   2. Selecting a Delivery or Pick-Up Option
   3. Submitting the Order
4. Conclusion

Introduction

In Part 1, we envisioned a global transportation software platform where third-party vendors and taxi companies can rapidly transport customers or goods within an hour, outlining our requirements, web/mobile apps, and overall flows. Part 2 provided a deep dive into the backend infrastructure and service architecture for the platform.

Now, in Parts 3-8, we’ll explore the specific domains, subsystems, and services required to bring this platform to life. We begin here in Part 3 with the Vendor domain and the 3rd Party Shopping & Checkout domains.

Vendor

The Vendor domain encapsulates all platform subsystems related to third-party merchants and taxi companies. It manages critical aspects such as registration, configuration, business management, and reporting. Before customers can place orders, third-party merchants and taxi companies must register and configure their details within the platform.

Since vendors will interact with the platform at a much lower frequency compared to customer orders, services within this domain will handle relatively lower traffic.

Vendor Management

The Vendor Management sub-system will contain services required for onboarding when vendors first integrate themselves with our platform, managing their configurations, and retrieving analytics reports.

The Vendor Service will facilitate vendor onboarding and configuration updates. It will contain basic CRUD operations for onboarding, managing vendor details, and uploading required documentation to verify compliance. It will be accessed largely through the Operations Portal Web UI, allowing platform operations managers and vendors to manage vendor info efficiently.

Vendors will require robust analytics to optimize their operations, track performance, and manage their businesses. The Vendor Reports Service will provide APIs for retrieving analytics reports related to a vendor’s order volumes and patterns, delivery performance, and financials. The reports will be generated nightly as an asynchronous workflow using a map-reduce cluster, balancing computational efficiency with scalability. This ensures that vendors receive up-to-date insights while minimizing the computational load on real-time systems.

By enabling efficient vendor management and reporting, the Vendor domain sets the stage for seamless vendor integration and ensures that merchants and taxi companies can manage their operations with ease.

Services:

1. Vendor Service - manages vendor details, configurations, and onboarding workflows; provides CRUD operations via the Operations Portal.
2. Vendor Reports - serves analytics reports for each 3rd party merchant and taxi company; reports are generated as part of nightly async workflows.

3rd Party Customer, Shopping, and Checkout

Our platform is capable of supporting a variety of customer checkout experiences that cater to different business models, including:

• Traditional eCommerce website/app with multiple vendors (e.g. eBay, Walmart, Amazon)
• Gig-economy delivery app with multiple vendors (e.g. DoorDash, Instacart, Uber)
• Custom-built vendor websites/apps integrated into our delivery platform (e.g. Shipt).

Though our platform can easily support each of these checkout experiences, we will focus on the more complex use case where each merchant and taxi service has a custom-built website or mobile app integrated into our delivery platform via APIs. In this configuration, vendors maintain complete control over the customer experience with the customer not even needing to know that their order is being handled by our transportation platform.

This section outlines the Customer, Shopping, and Checkout domains 3rd party vendors will implement, emphasizing the interaction between vendor-specific customer experiences and our delivery platform.

Prior to engaging with our platform, customers will go through the 3rd party vendor’s Customer domain to register themselves, upload and manage their payment details, and add their default or preferred addresses.

Next, within the 3rd party vendor’s Shopping domain, customers browse and select the items they would like to order or the taxi services they require.

Once the order is all set, the customer submits the order through the 3rd party vendor’s Checkout domain. The Checkout domain processes the order payment, creates the billing statement, submits the order into our transportation platform, and shows order status updates to the customer.

To support these customer workflows, our backend APIs must deliver high performance and reliability. Low-latency (under 100ms) will be especially critical during pre-checkout prior to payment to optimize conversion rates for vendors. There are three primary call patterns:

1. Pre-Checkout (very low latency): Query available delivery windows or pick-up times and associated prices, providing the cart contents, delivery address, and pick-up address if applicable.
2. Checkout / Order Submission (transactional): Submit the order to the delivery platform after checkout and payment, ensuring reliability and security.
3. Post-Checkout: View the order’s status and estimated delivery / pick-up time.

Design Considerations:

• Low-Latency APIs for Pre-Checkout: The pre-checkout phase directly impacts vendors’ conversion rates so we must ensure highly responsive APIs (under 100ms).
• Secure Order Submissions: During the checkout phase, transactional integrity and resilience are paramount. APIs must handle failures gracefully with retries and idempotency.
• Scalable Post-Checkout Updates: As order volumes grow, the platform must efficiently handle frequent delivery status updates, leveraging caching and event-driven patterns.

Retrieving Delivery Window and Pick-Up Time Availability

As customers enter the pre-checkout flow to get ready to place their order, they will be presented a dynamic list of available delivery windows for shipments or pick-up times for taxi services. These will range from same-hour to a few days, each with associated pricing. Availability is determined by region, time, and the lead time of the order, categorized into long-lead and low-lead scenarios.

Long-Lead Orders

For orders scheduled well in advance, delivery windows are predicted using machine learning (ML) generated forecasts combined with real-time data updates. The number of drivers per geographic region and time window is stored in a database table, first initialized with the forecasted driver supply and then updated as orders are confirmed. Each time an order is submitted the supply of drivers for that region and time window will reduce, whereas each time an order is cancelled the supply will increase. This hybrid approach of forecasting combined with real-time updates, ensures accurate availability for a given time window from when orders first start to the window starting.

Low-Lead Orders

For time-sensitive orders and taxi services, delivery availability is determined in real time using driver proximity, eligibility, and likelihood of acceptance.

The remainder of this chapter is available via the email list or 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