Design the partner API that lets Google Maps users order DoorDash delivery in-app

Quick Overview

A technical product manager question about designing the API that lets Google Maps users order DoorDash delivery without leaving Maps. It tests end-to-end order flow mapping, endpoint and data model design, order tracking, idempotent ordering, error handling, partner reliability and how to measure the integration.

Design the partner API that lets Google Maps users order DoorDash delivery in-app

Company: Stripe

Role: Product Manager

Category: System Design

Difficulty: medium

Interview Round: Other

You are a product manager on Google Maps. Maps wants to partner with DoorDash so that someone looking at a business in Maps can order delivery from it without leaving Maps. Design the API for this integration: the calls between the two companies' systems, the data each call exchanges, and the main design decisions behind them. ```hint Follow one order Trace a single order from the moment a user sees a restaurant in Maps until the delivery arrives, noting which company owns the data at each step. The calls that must cross between the two systems fall out of that trace. ``` ### Clarifying Questions - Does the user complete checkout inside Maps, or does Maps hand off to the DoorDash app once the user picks a restaurant? - Which company is the merchant of record: who charges the card, issues refunds and owns customer support? - Does the user need a DoorDash account linked to their Google account, or can they order as a guest? - Is the scope restaurant delivery only, or also pickup, groceries and the other store types DoorDash serves? ### What a Strong Answer Covers - The end-to-end order journey and a clear split of responsibilities between Maps and DoorDash - A resource model and endpoints for store matching, availability, menus, price quotes, order placement, tracking and cancellation, with request and response shapes - Push versus pull for order status and courier location, with a reasoned choice - A safe, durable contract: account linking and authentication, idempotent order creation, quote expiry, versioning, rate limits and error codes - How the PM measures the integration's success and keeps Maps usable when the partner API degrades ### Follow-up Questions - A user is charged twice for one order after a network timeout. What in your API should have prevented it, and how do you fix the affected orders? - How would you change the design so Maps could add a second delivery partner without rebuilding the integration? - DoorDash's menu service goes down during the dinner peak. What does a Maps user see?

Overview: A technical product manager question about designing the API that lets Google Maps users order DoorDash delivery without leaving Maps. It tests end-to-end order flow mapping, endpoint and data model design, order tracking, idempotent ordering, error handling, partner reliability and how to measure the integration.

Stripe logo
Stripe
Mar 23, 2026
mediumProduct ManagerOtherSystem Design
0
0

You are a product manager on Google Maps. Maps wants to partner with DoorDash so that someone looking at a business in Maps can order delivery from it without leaving Maps. Design the API for this integration: the calls between the two companies' systems, the data each call exchanges, and the main design decisions behind them.

Clarifying Questions Guidance

  • Does the user complete checkout inside Maps, or does Maps hand off to the DoorDash app once the user picks a restaurant?
  • Which company is the merchant of record: who charges the card, issues refunds and owns customer support?
  • Does the user need a DoorDash account linked to their Google account, or can they order as a guest?
  • Is the scope restaurant delivery only, or also pickup, groceries and the other store types DoorDash serves?

What a Strong Answer Covers Guidance

  • The end-to-end order journey and a clear split of responsibilities between Maps and DoorDash
  • A resource model and endpoints for store matching, availability, menus, price quotes, order placement, tracking and cancellation, with request and response shapes
  • Push versus pull for order status and courier location, with a reasoned choice
  • A safe, durable contract: account linking and authentication, idempotent order creation, quote expiry, versioning, rate limits and error codes
  • How the PM measures the integration's success and keeps Maps usable when the partner API degrades

Follow-up Questions Guidance

  • A user is charged twice for one order after a network timeout. What in your API should have prevented it, and how do you fix the affected orders?
  • How would you change the design so Maps could add a second delivery partner without rebuilding the integration?
  • DoorDash's menu service goes down during the dinner peak. What does a Maps user see?