Répondre à la croissance de DoorDash avec une plateforme de configuration logistique en libre-service 

DoorDash s'est développé à partir de simples livraisons à des restaurants pour travailler avec une grande variété d'entreprises, allant de l'épicerie au commerce de détail en passant par les fournitures pour animaux de compagnie. Chaque entreprise est confrontée à ses propres contraintes lorsqu'elle s'efforce d'atteindre ses objectifs. Nos équipes logistiques - qui couvrent un certain nombre de fonctions, y compris les Dashers, l'affectation, les processus de paiement et les estimations de temps - cherchent à atteindre ces objectifs en mettant au point une variété de configurations pour chaque cas d'utilisation et chaque type d'entreprise. 

Bien que ce processus ait commencé avec un ensemble limité de configurations, l'ancien système a eu du mal à suivre la croissance de DoorDash dans de nouveaux secteurs verticaux. L'équipe d'affectation héberge à elle seule plusieurs fichiers dans GitHub pour maintenir le nombre croissant de préférences, certains d'entre eux pesant désormais plus d'un mégaoctet chacun. Le fait que ces préférences ne soient pas conservées dans des formats standard n'arrange rien : certaines sont des JSON, d'autres des CSV, et d'autres encore n'ont pas de format du tout. Maintenir ces fichiers et les mettre à jour à la vitesse de la croissance de DoorDash s'est avéré à la fois difficile et risqué, de nombreuses pannes s'étant produites en raison de configurations incorrectes. En outre, le système actuel fonctionne avec un ensemble limité de fonctionnalités, ce qui réduit la vitesse à laquelle de nouvelles capacités et expériences peuvent être lancées. 

Avec tout cela à l'esprit, nous avons entrepris de construire une nouvelle plateforme de configuration logistique qui pourrait non seulement répondre aux demandes d'aujourd'hui, mais aussi continuer à s'adapter à la croissance future de DoorDash.

Architecture actuelle

La figure 1 représente une version simplifiée et de haut niveau de l'architecture existante de DoorDash, dans laquelle les utilisateurs mettent à jour leurs préférences dans des fichiers GitHub, qui sont ensuite poussés vers le cluster Redis. Lors de la création d'une livraison, KafkaConsumer lit les données sur Redis, crée un objet de contrainte d'affectation de livraison (DAC), puis le stocke dans une table DAC via le service de livraison. Pendant l'exécution de l'affectation, DeepRed récupère ces informations auprès du service de livraison via Apollo et utilise ces configurations pour prendre une décision d'affectation. 

Défis et limites

À un niveau élevé, l'architecture actuelle présente un certain nombre de défis et de limites, notamment :

• Mise à jour des préférences en une seule ligne pour des milliers de magasins: DoorDash et ses partenaires commerciaux opèrent dans plusieurs pays et régions, chacun avec ses propres préférences spécifiques. À des fins d'affectation, les préférences sont définies à différents niveaux de granularité - niveau de l'entreprise, niveau du fournisseur, niveau du magasin, et ainsi de suite - ce qui donne un énorme fichier de préférences. Dans l'implémentation actuelle, des milliers de magasins partagent les mêmes préférences, ce qui crée une ligne unique avec des milliers de magasins. L'ajout, la suppression ou la modification de l'un d'entre eux génère une énorme demande d'extraction, dont l'examen est ardu et qui présente un risque important d'échec de l'implémentation. 
• Préférences involontaires: Étant donné qu'un seul bloc de magasins comporte plusieurs types de préférences, il est arrivé que les préférences soient mises à jour de manière involontaire.
• Difficultés d'audit et de gestion des versions: Bien que GitHub permette le contrôle des versions, un audit correct est entravé par des changements de configuration fortement mis à jour sur la même ligne.
• Le processus d'ajout de nouvelles préférences prend du temps: DeepRed prend en compte un grand nombre de signaux et de préférences lors des missions de livraison. Les nouvelles entreprises introduisent constamment des exigences supplémentaires, et ces nouvelles préférences doivent être ajoutées dans plusieurs systèmes. Dans l'architecture actuelle, ces préférences se trouvent dans la table DAC, KafkaConsumer, Apollo, le service de livraison, les clients en amont (qui définissent les préférences), puis DeepRed, ce qui crée un processus qui peut prendre jusqu'à une semaine.

L'architecture actuelle présente également des limitations de niveau inférieur et des capacités manquantes, notamment :

• Pas de moyen d'ajouter des configurations éphémères pour mener des expériences: Chez DoorDash, nous croyons qu'il faut mener de nombreuses expériences pour obtenir les bonnes valeurs pour toutes nos parties prenantes. Idéalement, nous aimerions mener des expériences sur des configurations ad hoc, mais il n'y a actuellement aucun moyen de les ajouter temporairement et de manière évolutive.
• Les préférences ne sont pas en temps réel : Lorsqu'une livraison est créée, les DACs correspondants sont également créés ; DeepRed doit prendre en compte ces contraintes supplémentaires au cours du processus d'affectation. Chaque DAC n'est créé qu'une seule fois, donc si certaines préférences ont été modifiées avant que DeepRed ne récupère l'objet, ces nouvelles préférences ne sont jamais prises en compte pour l'affectation. Ceci est particulièrement gênant pour les livraisons programmées et cause également des maux de tête lors du débogage. De nombreux incidents se sont produits lorsque la livraison a été créée avant que les nouvelles préférences aient pu être définies.
• Pas de source unique de vérité : les CAD sont prédéfinis au niveau de l'entreprise ou de l'entité, mais des mises à jour dynamiques des préférences sont également nécessaires au niveau de la livraison. Au lieu de cela, les CAD sont mis à jour par le service de commande lors de la création de la commande, mais il n'y a aucun moyen de savoir si ces préférences ont été créées par le service de commande ou si elles proviennent de valeurs prédéfinies. 
• Utilisation incorrecte des préférences existantes : En raison de l'effort requis pour inclure de nouvelles préférences, il arrive que des préférences existantes avec des valeurs magiques soient utilisées pour obtenir certains résultats.

Résoudre les problèmes liés à une plate-forme de configuration logistique

Pour relever tous ces défis, nous avons créé une plateforme de configuration logistique qui fournit une source unique de vérité avec une fiabilité, une évolutivité, un audit et une vélocité améliorée. Nous avons inclus une interface utilisateur intuitive - LxConsole - au-dessus de la plateforme. Chaque configuration à un niveau élevé est indépendante, versionnée et contrôlée à la fois par l'historique et l'approbation.

Résoudre les problèmes existants

Notre nouvelle architecture réduit considérablement le temps nécessaire pour ajouter un nouveau type de préférence ; ce qui prenait plus d'une semaine peut être fait en moins d'une journée. En outre, l'audit et le contrôle des versions sont rationalisés, chaque demande de configuration entraînant l'entrée d'une version plus récente dans la base de données. Par défaut, chaque configuration est créée dans un état de révision. Les parties prenantes concernées peuvent alors examiner la demande et l'approuver ou la rejeter. Ce processus fournit un chemin d'audit beaucoup plus clair, montrant qui modifie quoi, quand et pourquoi. La nouvelle architecture présente chaque demande sur une ligne distincte, comme le montre la figure 2 ci-dessous, ce qui permet à l'examinateur de voir à la fois la valeur demandée et l'ancienne valeur. Le premier graphique de la figure 2 montre les résultats impénétrables de notre ancien système.

Avant

Voici des captures d'écran partielles des résultats de git-diff d'une demande de mise à jour de deux configurations de magasins :

Après

Construire de nouvelles capacités

Outre la résolution des problèmes existants, la plateforme offre de nombreuses nouvelles fonctionnalités :

• Configuration basée sur l'expiration : DoorDash a de nombreux cas d'utilisation qui nécessitent de définir des configurations pour un certain temps, puis de les annuler automatiquement. Cela réduit le temps et les efforts nécessaires à la gestion de la configuration et évite également d'oublier de revenir en arrière.
• Préférences temporelles : Chaque entreprise et chaque secteur vertical souhaitent des paramètres différents à différents moments de la journée. Dans cette nouvelle plateforme, les entreprises peuvent soumettre des valeurs de préférence pour chaque fenêtre temporelle ; la plateforme peut alors renvoyer des valeurs basées sur ces heures (en tenant compte des différents fuseaux horaires). Le client n'a donc pas à stocker chaque configuration, ni à effectuer un traitement complexe de l'heure et de la date. Au lieu de cela, les clients peuvent simplement soumettre leurs préférences et obtenir les résultats appropriés. Les entreprises peuvent ainsi affiner leurs préférences pour obtenir de meilleurs résultats, comme le montre cet exemple :

Time Window based configuration:
{ 
    { StartTime: “0”, EndTime: “10”, value: “10”} 
    { StartTIme: “11”, EndTime: “23”, value: “20”} 
} 

• Types de configuration éphémères : De nombreuses équipes DoorDash mènent des expériences sur les préférences, mais toutes les expériences n'aboutissent pas à une configuration finale. Nous avons donc besoin d'un moyen d'ajouter des types de configuration ad hoc pour mener des expériences sans les gonfler car les types de configuration sont principalement pour les préférences à long terme plutôt que pour les préférences expérimentales à court terme. Nous avons inclus dans la nouvelle plateforme un support pour l'ajout de nouvelles préférences - des configurations éphémères - qui ne nécessiteraient pas d'effort de la part des développeurs. Cela prenait environ deux semaines, mais les nouvelles configurations permettent désormais aux équipes de lancer des expériences en moins d'une journée.
• Validation : Actuellement, il n'y a pas de logique de validation pour les différentes préférences. La nouvelle plateforme, cependant, effectue des validations et rejette automatiquement les demandes qui ne satisfont pas à des critères prédéterminés. Cela représente un gain de temps considérable tant pour le demandeur que pour l'approbateur.
• Approbation/rejet automatique : Au fur et à mesure que nous intégrons davantage de cas d'utilisation avec une fréquence élevée de mises à jour et certaines validations en place, nous pouvons sauter l'approbation manuelle pour certaines demandes. À un niveau très élevé, la nouvelle plateforme procédera à une approbation automatique dans deux cas :
  • Approbation/rejet automatique basé sur le type : Dans ces cas, toutes les demandes pour un certain type de configuration seront automatiquement approuvées. Nous commençons par les capacités de stockage, qui sont des configurations fréquemment mises à jour par les opérateurs pour ajuster la répartition.
  • Approbation/rejet automatique basé sur des règles: Dans certains cas, nous pouvons approuver automatiquement une demande lorsque certaines conditions sont remplies. Par exemple, si la validation pour un type de configuration donné est réussie et qu'elle est soumise par un certain groupe de personnes, le système peut approuver automatiquement la demande. 
• Extensible à n'importe quel type de configuration : Avec JSON comme type, le client peut théoriquement soumettre n'importe quelle configuration arbitraire et commencer à l'utiliser en moins d'une journée. La nouvelle plateforme effectue des validations de base pour le type JSON et peut ajouter des validations supplémentaires en fonction du type de configuration. La plateforme est extensible, de sorte que toute entreprise peut venir ajouter ses propres validations en plus de la validation de base. Grâce à cette conception, les clients peuvent commencer à utiliser la plateforme de configuration immédiatement et peuvent également ajouter un support supplémentaire en cas de besoin.
• Configuration basée sur l'expérience : Les ingénieurs peuvent facilement configurer leur expérience et écrire un blob JSON avec les métadonnées requises telles que le nom de l'expérience, le contrôle et les valeurs de traitement, comme illustré ici :

{
     experimentName: pizza_bag_hold_out
     Control: 1,
     Treatment: 
     {
             T1: 2
             T2: 3
     }
}

Modèle de données

Voici le modèle de données simple utilisé dans le système, avec une explication de chaque champ et un exemple :

Schéma

• Clé primaire: 
  • domain:entityType:entityId:configType:version
• Autres domaines:
  • value_type: Int, Double, String, Boolean, JSON etc.
  • config: valeur basée sur value_type
  • config-status: Approuvé/Rejeté/Expiré/Supprimé, etc.
  • requester/approver/creationDate/description : autres métadonnées

Explication

• Domaine: espace de noms (Pay, Assignment, Dx, etc.)
• entityType: store, business, SP, Delivery (plus à ajouter)
• entityId: <ID based on type>
• configType: <predefined type>
• version: Incrémentation automatique à chaque demande

Exemple

Extensible à tout type d'entité: Comme indiqué plus haut, DoorDash travaille à différents niveaux de granularité. Cette nouvelle plateforme permet d'ajouter des configurations à tous les niveaux. Avec le schéma présenté dans la figure 3 ci-dessus, la plateforme peut définir des configurations à n'importe quel niveau d'entité. Par exemple, si demain il est nécessaire de définir une préférence au niveau de l'État, les utilisateurs peuvent simplement l'ajouter sans qu'il soit nécessaire d'apporter d'autres modifications que la mise à jour des listes, qui contrôlent ce qui entre dans le système. Comme pour d'autres parties de la conception, ce modèle de données a été finalisé après de multiples itérations. Jusqu'à présent, il a fonctionné pour tous les cas d'utilisation prévisibles.

Enseignements tirés

Cette section résume les enseignements fondamentaux que nous avons tirés de notre architecture existante et de notre transition vers la nouvelle plateforme. Ces enseignements clés ouvrent la voie à l'approche pragmatique et avant-gardiste que nous adopterons au cours des prochaines étapes, garantissant ainsi une base solide pour le voyage à venir. 

• Voir grand, commencer petit : il s'agissait d'une stratégie de développement clé pour la plate-forme dès le premier jour. Lorsque nous avons commencé le projet, nous n'étions pas certains des capacités et des exigences des clients qui seraient incluses. Nous nous sommes donc concentrés sur un concept de base : Construire de petits composants solides comme le roc, puis itérer à partir d'eux.
• Temps de latence : We started with a basic CockroachDB cluster (CRDB) and three Kubernetes PODs per cell. This gave us enough performance to achieve our minimum viable product goals. We started with 300 queries per second (QPS) with p99 <10 ms; all of these were non-batched requests. As we started onboarding additional use cases and traffic, latency increased. We had to identify and fix a few problems to get latency back to where we wanted it.
  • The first bottleneck we hit was when we opened traffic for batched calls from the snapshotting stage. Our latency shot from <10 ms to 500 ms for those batch calls. We moved from the default coroutine dispatcher to io-dispatcher, which increased parallelism. This improved our latency for batch calls from 550 ms to 350 ms, which was sufficient for our use case. Nonetheless, we continued to pursue improvements. 
  • Après une analyse plus approfondie du côté client, nous avons réalisé que nous étions censés créer de petits lots ; à cause d'un petit bogue, nous faisions un seul appel avec 2000 ID au lieu d'un lot de 100 et nous étions confrontés à des doublons d'ID. Une fois ces problèmes résolus, notre temps de latence est passé de 350 ms à 40 ms.
  • Cet appel de lot a été limité par l'indicateur de fonctionnalité, qui n'a été activé que pour un sous-ensemble de types d'entités et d'identifiants d'entités correspondants. Lorsque nous avons ouvert l'ensemble du trafic à config-service, notre temps de latence a de nouveau augmenté, passant de 40 ms à environ 700 ms. Nous avons mis à jour le type d'instance de notre cluster CRDB, ce qui a permis d'améliorer la latence de 700 ms à 450 ms.
  • Nous avons plongé plus profondément pour continuer à améliorer la latence. Bien que le QPS vers config-service n'ait pas beaucoup augmenté - de 350 à 500 - le QPS de pointe de config-service vers CRDB est passé de 400 req/sec à 20 000 req/sec. Cela s'explique par le fait qu'une seule requête globale (avec 1000 entités) a été divisée en requêtes individuelles vers CRDB (1000 requêtes). Après avoir modifié notre requête de = clause de IN En utilisant la clause d'utilisation d'identifiants d'entités multiples, la latence est revenue à un niveau normal d'environ 40 ms, avec le même QPS pour config-service et CRDB (figure 4).

• Tests d'intégration et tests locaux : Avant même de lancer notre MVP, , nous avons intégré des tests d'intégration et des tests locaux dans notre système, ce qui nous a permis de détecter les bogues et de réaliser des tests locaux à chaque étape. Cela nous a également permis de construire nos itérations en toute confiance.
• Composants découplés et modèles d'interrogation : Bien que nous ayons créé un point final unique pour tous les cas d'utilisation de la recherche, nous avons créé des gestionnaires spécifiques à chaque cas d'utilisation. Cela nous a permis d'obtenir
  • Des requêtes distinctes pour des cas d'utilisation distincts : Sur la base des cas d'utilisation, nous avons optimisé nos requêtes de manière répétée ; la mise à jour d'une requête pour un cas d'utilisation n'interférait pas avec les autres requêtes.
  • Flexibilité pour déplacer plusieurs points d'extrémité : Cela nous donne également la possibilité de diviser notre point de terminaison unique en plusieurs points de terminaison en fonction des cas d'utilisation sans apporter de modifications à nos gestionnaires internes. Par exemple, nous pourrions créer des points de terminaison distincts pour l'interface utilisateur et les appels de service.
• Utiliser les solutions prêtes à l'emploi lorsqu'elles sont disponibles : Il est toujours préférable de déployer des solutions prêtes à l'emploi. L'équipe de la plateforme interne de DoorDash a déjà construit de nombreuses fonctionnalités qui s'avèrent utiles, comme un microservice basé sur Asgard, qui vient avec un bon ensemble de fonctionnalités intégrées comme les métadonnées des demandes, la journalisation, et l'intégration du cadre de valeur dynamique. 

Les défis de la migration

Notre plus grand défi a été de migrer les préférences existantes alors même que l'ancien système était activement modifié. De nombreuses parties prenantes continuant à mettre à jour le GitHub existant, il a été difficile de maintenir la parité avec le nouveau système. Dès le départ, nous avons adopté quelques bonnes pratiques pour rationaliser le processus, notamment :

• Un bon cadre de parité et des scripts de migration : Nous avons construit un cadre de parité pour comparer les résultats entre la plateforme et le runtime. Exécuté en temps réel, ce framework peut générer des logs et des métriques s'il y a des différences entre les deux systèmes. Il a également permis de passer des anciennes préférences aux nouvelles avec une petite configuration.
• Scripts : Les scripts nous ont aidés à convertir les données au format final (CSV), ce qui nous a permis de gagner beaucoup de temps.
• Un guide clair avec des exemples de fichiers et un outil de suivi : Nous avons préparé un guide et un suivi afin de maintenir la clarté sur les configurations qui ont déjà été migrées, celles qui sont en cours, et sur la façon de préparer les données pour chaque type de configuration. 
• La communication : Il a été essentiel de maintenir une communication claire à tous les niveaux. Nous avons communiqué de manière proactive avec nos parties prenantes sur ce qui a été lancé, sur ce qui reste à faire, sur la manière d'utiliser la nouvelle plateforme et sur l'endroit où trouver toute information supplémentaire dont ils pourraient avoir besoin. Nous surveillons également les modifications apportées à GitHub afin de pouvoir demander immédiatement aux parties prenantes d'utiliser le nouvel outil. Cela présente deux avantages : Pas d'erreurs de parité et une intégration immédiate des partenaires.

Prochaines étapes

Maintenant que nous avons examiné ce que nous avons appris de notre architecture existante, concentrons-nous sur ce qui nous attend. La nouvelle architecture, appelée LxConfig Platform, nous permet de profiter de nombreux nouveaux avantages, notamment : 

• Plus de clients et de cas d'utilisation : Nous avons récemment lancé notre MVP et sommes impatients d'y ajouter de nouvelles fonctionnalités. La plateforme LxConfig est devenue un élément central pour toute une série d'objectifs que nous nous sommes fixés pour l'année prochaine et au-delà. La plateforme est en train de devenir une norme de facto pour le stockage des configurations. Nos premiers utilisateurs étaient l'équipe des affectations, et nous travaillons activement à l'intégration de nouvelles équipes, telles que pay, ETA, Drive.
• Architecture simplifiée : Comme indiqué précédemment, nous nous efforçons de simplifier l'architecture du système d'affectation en supprimant un certain nombre de composants inutiles, comme le montre la figure 5 ci-dessous :

• Mise à l'échelle : Nous traitons actuellement 500 requêtes/s avec moins de 10 ms de latence (p99) pour les appels non groupés et 40 ms pour les appels groupés. Au fur et à mesure de l'augmentation du nombre de clients et des cas d'utilisation, nous devons augmenter ce chiffre à 10 000 req/s tout en maintenant une latence aussi faible que possible.
• Configuration basée sur des règles : Tout comme les différentes configurations requises pour les différentes désignations de temps, certaines conditions requièrent également des configurations spécifiques. Actuellement, le client doit créer une logique personnalisée et effectuer le traitement. Avec la configuration basée sur des règles, cependant, les clients peuvent définir des configurations avec des règles discrètes lorsqu'ils soumettent la demande. Lors de la récupération, l'utilisateur peut choisir de passer un paramètre de filtrage, que la plateforme peut utiliser pour renvoyer différentes valeurs, comme illustré ci-dessous :

{
      Predicate: {
          delivery_subtotal: >50
      },
      Preference: {
          Risk_score: >30,
          Shop_score: >20
      }
}

• Conception du modèle de permission : Seule l'équipe de la plateforme est actuellement autorisée à approuver les demandes, ce qui n'est pas une solution évolutive à long terme. Tout d'abord, l'équipe de la plateforme n'a pas d'informations sur le type de modifications demandées. Deuxièmement, les approbations consommeraient beaucoup trop de bande passante de la part des ingénieurs de l'équipe de la plateforme. Alors que nous travaillons avec l'équipe d'identité et de sécurité pour construire un modèle de permissions sophistiqué, nous développons notre propre modèle basé sur le type de configuration pour étendre l'ensemble des personnes capables d'approuver certaines demandes.
• Optimisation : Nous recherchons en permanence les points sensibles en matière de logique et d'interrogation qui pourraient être améliorés au fil du temps. 
• Fiabilité : Nous veillons à fixer des attentes réalistes pour cette nouvelle plateforme à mesure que nous intégrons des clients et des cas d'utilisation. Nous continuons à renforcer la résilience de notre système en ajoutant davantage de points d'extrémité à nos objectifs SLO, en affinant nos mesures et en développant nos ressources infra, entre autres. Nous continuons à travailler sur la capacité de cette plateforme à prendre en charge les services T0 et les contraintes strictes. Tous les clients actuels de la plateforme sont des services T0, ont des solutions de repli en place et peuvent fonctionner de manière dégradée si la plateforme devient indisponible.
• Traitement asynchrone des demandes : La plateforme actuelle peut traiter environ 30 000 lignes de fichiers CSV en une seconde environ lors d'un appel de synchronisation. Cette capacité devra être augmentée lorsque nous commencerons à intégrer des configurations de mise à jour quotidienne pouvant inclure jusqu'à 100 000 lignes. Cet objectif peut être atteint de manière synchrone en trouvant et en améliorant les limites actuelles, en maintenant la latence à moins d'une seconde, ou de manière asynchrone en découplant la soumission et le traitement des demandes. Le passage à l'asynchronisme apportera des fonctionnalités supplémentaires et plusieurs avantages, notamment
  • Construire un meilleur cadre pour les chemins d'écriture, en divisant les demandes les plus importantes en parties plus petites ; 
  • Permettre des réussites et des échecs partiels et fournir aux utilisateurs des détails sur les réussites et les échecs.
  • Mise à l'échelle à très haut niveau d'entrée ; et
  • Faciliter le traitement des demandes soumises par le système.

• Nouveaux points d'accès : Actuellement, les demandes sont soumises uniquement par le biais de la LxConsole. Comme nous nous dirigeons vers la prise en charge de cas d'utilisation dans lesquels les configurations sont mises à jour dynamiquement en fonction du type de commande ou par le biais de modèles ML, nous avons besoin de meilleures méthodes pour stocker ces demandes. Le fait d'avoir des points de terminaison distincts pour ces demandes permettra de limiter et d'isoler le rayon d'action.
• Nouveaux formats d'entrée : Actuellement, la plateforme prend en charge les entrées basées sur les octets. Nous souhaitons passer à d'autres formats, y compris ceux basés sur les fichiers et les enregistrements.
• Migration facile : Avec de nombreuses configurations réparties sur plusieurs sites dans une variété de formats, nous devons améliorer les moyens de les déplacer vers le config-service. Actuellement, nous envisageons de les convertir au format requis par la plate-forme config si ces configurations sont générées par un système qui peut être mis à jour pour utiliser un nouveau format. Sinon, nous pouvons construire un cadre au sein de la plateforme config pour consommer les CSV et créer automatiquement des JSON à partir d'eux. Ce processus est en cours pendant que nous déterminons l'option qui fonctionnera le mieux. 
• Consommation automatique : Alors que la plateforme config est alimentée manuellement en données pour le moment, nous voulons construire un système pour certains cas d'utilisation afin de permettre à la plateforme de vérifier et d'extraire périodiquement la configuration d'un système généré automatiquement, y compris éventuellement une configuration générée par un modèle de ML. 
• Configuration brute et dérivée : Nous développons également des capacités de stockage des données de configuration brutes et dérivées dans le service config pour la consommation et l'analyse. Les détails sont en cours de discussion, mais nous sommes enthousiastes à l'idée de poursuivre cette idée.
• Améliorer la vélocité des développeurs et des partenaires : Bien que nous disposions actuellement d'un bon cadre de test local, nous avons parfois besoin de bacs à sable pour effectuer des tests de bout en bout. Nous prévoyons d'améliorer notre plateforme avec des bacs à sable qui sont en ligne avec le reste de DoorDash. Cela permettra aux développeurs de créer de nouveaux environnements et d'effectuer des tests de bout en bout plus rapidement.
• Amélioration de l'environnement de test : Actuellement, LxPlatform n'a pas de point d'arrivée pour les tests. Pour cette raison, les clients se connectent à l'environnement de production pour leurs tests. En fonction du nombre de clients, cela pourrait augmenter de manière significative le QPS. Nous envisageons de construire un environnement parallèle non prod pour les tests de bout en bout sans affecter l'environnement prod. 
• Affiner le modèle de données : Au fur et à mesure que les cas d'utilisation se multiplient, nous voulons maintenir un certain niveau de contrôle tout en permettant une certaine flexibilité quant au type de données à stocker. Dans le modèle actuel, configType est une valeur unique, mais nous envisageons de le diviser en deux niveaux : configType et configSubType. Avec ce changement, un certain type de configuration peut avoir un nombre illimité de sous-types sans qu'il soit nécessaire de mettre à jour les énumérations pour les nouveaux cas d'utilisation subordonnés.
• Pipeline pour l'entrepôt de données : Nous travaillons à la mise en place d'un pipeline pour déplacer les données de la base de données principale vers un lac de données pour un stockage à long terme, offrant un accès facile pour l'analyse. Cela permettra de réduire la taille de la base de données principale et d'améliorer les performances. 
• Enregistrement en libre-service de nouveaux types de configuration : Un objectif de moindre priorité consisterait à offrir aux partenaires une option en libre-service leur permettant de définir leurs propres types de configuration. Toutes les propriétés définies pour ces types de configuration feraient partie du processus d'enregistrement. Cela éviterait à la plateforme d'avoir à modifier le code pour les nouveaux types de configuration. 

Dernières réflexions

Nous avons commencé par une grande vision et nous continuons à avancer dans cette direction, étape par étape, en apprenant au fur et à mesure. La création de la plateforme n'était qu'un début. Nous sommes enthousiasmés par les possibilités de croissance continue, car nous continuons à itérer et à améliorer le système pour répondre aux besoins en constante évolution de l'activité croissante de DoorDash.

Si vous êtes passionné par la création de produits innovants qui ont un impact positif sur la vie de millions de commerçants, de Dashers et de clients, envisagez de rejoindre notre équipe.

Remerciements

Merci au groupe de travail, à Ben Fleischhacker et à Ashok Thirumalai pour leurs contributions à la discussion, à la conception et à l'exécution. Merci à Paul Brinich et Gayatri Iyengar pour leur soutien constant au projet. Merci à Sameer Saptarshi, Suhas Khandiga Suresh et Ryan Xie pour leur travail en tant que partenaires et contributeurs. Merci à Joy Huang et Lillian Liu pour avoir examiné les perspectives du produit.

Enfin, je tiens à remercier Janet Rae-Dupree, Robby Kalland et Marisa Kwan pour leur soutien constant lors de la révision et de l'édition de cet article.