THE MIGRATION LINE
INCIDENT // DOORDASH-2026SHIPPED

DoorDash rebuilt Dasher onboarding — three coexisting API versions, hard-coded per-country logic, and status scattered across multiple tables — into a single configurable workflow platform, then migrated every market onto it starting with the US, with zero user-facing regressions in any launch.

DOORDASH·2026·INFRA / ARCHITECTURE / WORKFLOW / BACKEND·✓ Sourced — careersatdoordash.com
System stress over timeNominal
January 2025US migration
~1 week (Puerto Rico)Fastest market migration
US, AU, CA, PR, NZMarkets migrated
zeroUser-facing incidents
BEFORE

Three onboarding API versions, and country logic buried in if/else chains

As DoorDash expanded into new countries, its once-streamlined Dasher signup flow evolved into a tangle of region-specific logic, custom validations, and disconnected systems, with the onboarding experience varying widely even within a single country.

AFTER

Every market on one platform, launched with zero regressions

The United States, DoorDash’s largest and most complex market, fully migrated onto the new architecture for all new Dasher signups in January 2025 — validating the core design before the rest of the world followed. Australia migrated in under a month, needing only two new localized steps. Canada took two weeks, reusing nearly every existing module. Puerto Rico took about a week. New Zealand required almost no new development at all. Every single migration launched with zero regressions, no onboarding downtime, no spike in support tickets, and no unexpected drop in completion rates.

THE BRIDGE

Onboarding as composable steps, not a hard-coded sequence

DoorDash redesigned onboarding as a configurable, event-driven workflow platform: each onboarding action — identity verification, a compliance check, document upload — became an independent, self-contained module exposing a standard interface, with its own owning team, able to be tested and iterated in isolation. A lightweight orchestration layer selected which workflow definition applied based on country or market type and routed the request accordingly, and a unified “status map” replaced the old scattered status tables, with each step responsible for updating its own state directly.

To migrate without a risky all-at-once cutover, the new platform ran side by side with the legacy V2 and V3 APIs, letting teams onboard new applicants and markets on the new system while old integrations kept working. Applicants who had partially completed onboarding under the legacy system were kept in sync through temporary synchronization mechanisms so nobody lost progress mid-migration.

COST

A years-long effort, still validated market by market

DoorDash built this as a multi-year platform effort, not a single project — the team explicitly designed for global scale from the outset rather than patching the legacy system market by market, which paid off directly as each subsequent country migration got faster than the one before it. The ongoing integration of Dasher onboarding with another large, independently developed onboarding ecosystem is still underway, continuing to test and refine the platform’s modular design against requirements it wasn’t originally built for.

A platform’s reusability isn’t a claim you can verify from its architecture diagram — it’s proven by whether each new market takes less time to onboard than the last one did.

Source — read the original

A plain-language, AI-drafted and human-edited retelling of the article published on careersatdoordash.com, reorganized and explained in our own structure and words, with original analysis in the editor's note above. The facts, numbers, and decisions belong to the original author and are not altered. For the full depth, read the source.

← All systems