DoorDash ofrece una experiencia de prácticas inmersiva en la que todos nuestros becarios se integran plenamente con los equipos de ingeniería para obtener una experiencia real en el sector que no se enseña en las aulas. Este es el primero de una serie de posts que mostrarán algunos de los proyectos de nuestros becarios del verano de 2022. A continuación puedes leer sobre cada proyecto.

Contenido: 

• DoorEye - Supervise la información del modelo ML y la variación de la producción a escala- Por Wenfei Tang
• Creación de una herramienta DevOps de código promocional para comprender mejor las campañas- Por Jayeon Koo
• Ampliación de Kubernetes Horizontal Pod Autoscaler- Por Jianna Liu 
• Creación de una nueva infraestructura de herramientas internas para mejorar la experiencia de atención al cliente de DoorDash- Por Michael Yu
• Creación de banners de notificación extensibles en todas las páginas- Por Xiaochuan Xu

DoorEye - Supervise la información del modelo ML y la variación de la producción a escala

Por Wenfei Tang

Estamos construyendo DoorEye para ayudar a nuestros usuarios del Equipo de Ciencia de Datos y Aprendizaje Automático (Equipo DSML) a monitorizar los modelos ML en producción y mejorar la observabilidad de los modelos ML en DoorDash.

¿Por qué controlar los modelos?

La monitorización de modelos es crucial en el ciclo de vida de un proyecto de ML porque después de que un modelo se despliega en producción queremos asegurarnos de que está funcionando como se esperaba. Los modelos de ML pueden sufrir desviaciones o variaciones de producción tras su puesta en producción. La monitorización de modelos, el proceso de supervisión de la calidad de estos modelos de ML, puede ayudarnos a detectar estos problemas y proporcionar una evaluación del modelo a largo plazo. También podemos planificar el reentrenamiento de los modelos en función de los resultados de la supervisión. 

Problemas con el enfoque de supervisión heredado

Anteriormente, nuestros usuarios del Equipo de Ciencia de Datos y Aprendizaje Automático (Equipo DSML) supervisaban el rendimiento de sus modelos utilizando un método manual y poco escalable. Este método suponía un reto por varias razones: 

• Era ineficaz y no se adaptaba lo suficiente a nuestras necesidades. Nuestros usuarios suelen tener que ejecutar manualmente secuencias de comandos de supervisión para observar el rendimiento de sus modelos en producción y tienen que configurar una secuencia de comandos distinta para cada modelo.
• La trazabilidad era un reto. No podíamos conectar las métricas del modelo creado con la fuente de métricas.
• No se proporciona el historial de rendimiento. Las métricas del modelo y los conjuntos de datos etiquetados no se almacenan. Esto impide a nuestros usuarios analizar los datos históricos de rendimiento del modelo. También es difícil ejecutar estas secuencias de comandos con una cadencia regular y sólo son aptas para realizar una evaluación puntual del rendimiento. 

Nuestra solución: marco de supervisión de modelos con interfaces declarativas

Nos gustaría apoyar a nuestros usuarios del equipo DSML construyendo DoorEye, un marco de supervisión de modelos que permite a nuestros usuarios supervisar las perspectivas de los modelos y la varianza de la producción a escala. DoorEye admite la evaluación de modelos fuera de línea activada automáticamente, la visualización de estadísticas de modelos calculadas mediante nuestra interfaz de usuario de métricas comunes, el almacenamiento automatizado de conjuntos de datos etiquetados y métricas de rendimiento en el lago de datos, la recuperación de datos históricos del lago de datos y las alertas basadas en umbrales para la detección de desviaciones de modelos. Estamos construyendo DoorEye para que pueda convertirse en una ventanilla única de información sobre modelos de productos para nuestros usuarios.

Principales resultados e impacto de DoorEye

Tras crear y poner en marcha DoorEye, pudimos mejorar la calidad y la productividad del proceso de supervisión de modelos para nuestros usuarios internos.

Ahora, nuestros usuarios sólo tienen que enviar un único archivo de configuración a un repositorio centralizado, en lugar de crear un script de supervisión distinto para cada modelo. DoorEye desencadena automáticamente la tarea en función de la programación proporcionada por los usuarios (véase la figura 1) y completa el resto del flujo de trabajo para la supervisión de modelos. A continuación, los usuarios tendrán acceso directo a paneles con estadísticas de modelos personalizadas y segmentación de datos (véase la figura 2), y podrán recuperar datos de Data Lake (AWS S3). DoorEye también hace que la monitorización de modelos sea más rentable porque podemos detectar rápidamente trabajos fallidos para nuestros usuarios con un repositorio centralizado y evitar el desperdicio de recursos informáticos. Hasta ahora, los comentarios del equipo han sido positivos y aprecian lo mucho que facilita la monitorización de modelos en producción. 

En general, DoorEye completa el paso de despliegue y supervisión en el ciclo de vida de un proyecto de ML. Aborda la velocidad de creación de nuevas métricas para los modelos mediante la automatización y estandarización del proceso de evaluación de modelos fuera de línea, y permite a nuestros clientes supervisar las percepciones de los modelos y la varianza de la producción a escala.

Creación de una herramienta DevOps de código promocional para comprender mejor las campañas

Por Jayeon Koo

Con iniciativas como Summer of DashPass que crecen cada año, el equipo de ingeniería de promociones tiene que intervenir regularmente cuando los códigos promocionales no funcionan. Aunque los errores de los códigos promocionales parecen sencillos, a menudo la única respuesta es que hay un error cuando los consumidores intentan utilizar un código en la caja. Por lo tanto, necesitábamos crear una herramienta de automatización de la implementación que ayudara a depurar códigos promocionales defectuosos mediante la recopilación de eventos de validación de promociones y que permitiera a los ingenieros consultar esos datos con consultas flexibles. En este artículo, trataremos el reto técnico con más detalle y explicaremos cómo creamos la herramienta para resolverlo. 

Razones por las que los códigos promocionales pueden no funcionar para un pedido

Existen muchas condiciones diferentes que debemos comprobar antes de permitir que un cliente utilice un código promocional; si un código promocional se autentica de forma aleatoria, esto puede provocar fácilmente una afluencia de pedidos fraudulentos. Cuando intentamos depurar problemas relacionados con los códigos promocionales, tanto los ingenieros como los consumidores sólo reciben un mensaje de error sin más especificación de lo que ha provocado el mensaje de error. El mensaje de error sería algo así como "Algo ha ido mal con la promoción, por favor inténtelo de nuevo más tarde". El mismo mensaje de error puede tener diferentes causas. Así, aunque los códigos de promoción fallen por diferentes motivos, a menudo mostrarán el mismo mensaje genérico a los clientes, e incluso a los desarrolladores. Comprender el problema implica un largo proceso de identificación de la campaña en nuestra base de datos, recopilación de información sobre la experiencia del cliente o del ingeniero que detectó el error por primera vez, intento de reproducir el error desde una cuenta de empleado y comprobación de los registros en los terabytes de registros que recopilamos cada día. Se trata de un largo proceso de depuración que nos gustaría automatizar en la medida de lo posible para facilitar la creación y el mantenimiento de las promociones.

Creación de la herramienta DevOps para depurar los problemas del código de promoción 

Para eliminar el doloroso proceso de depuración que supone arreglar un código de promoción defectuoso, el equipo de ingeniería de promociones decidió crear una herramienta interna que actuara como solución única para recopilar automáticamente toda la información relevante sobre un evento de validación de promoción. En lugar de reproducir manualmente el error para ver dónde podría haber fallado, esta herramienta dispondrá de información suficiente para dar directamente una idea de lo que ha ocurrido con el pedido. La figura 1 esboza la estructura de alto nivel de este proyecto en dos subsistemas: ruta de escritura y ruta de lectura, o recogida y análisis de datos. Esta clasificación ayuda a desglosar el proyecto en el orden de ejecución y la secuencia de rutas de información. A continuación explicaremos el proceso de construcción de esta herramienta utilizando esta clasificación.

Ruta de escritura: recopilar la información adecuada

El primer paso de esta herramienta es asegurarse de que la información en cuestión se registra de forma precisa y exhaustiva en la base de datos. Para depurar un código de promoción que falla, la información útil incluye el código de promoción, el ID único del consumidor, los artículos dentro del carrito en el momento del uso de la promoción, la marca de tiempo y los mensajes de error de cada intento. Todos los datos registrados de los códigos de promoción se guardaron en una tabla de base de datos independiente para agilizar la consulta de datos. Esta información puede analizarse y consultarse a través de la implementación de la ruta de lectura de esta herramienta DevOps.

Ruta de lectura: consulta de la información deseada

Ahora que hemos recopilado los datos en una tabla separada, necesitamos una herramienta para consultar esa información para facilitar el acceso y mejorar la experiencia del usuario. Utilizando BloomRPC, que es una interfaz gráfica de usuario para gRPC, configuramos un punto final para consultar la base de datos recién creada. El objeto de consulta incluye varios campos, como el código de promoción, el identificador de la tienda y la hora de inicio y fin, para permitir prácticas de consulta flexibles, como se muestra en la figura 2. Por supuesto, la base de datos sigue estando disponible para los usuarios. Por supuesto, la base de datos sigue estando disponible para que los desarrolladores utilicen la información al máximo.

Cómo la herramienta DevOps ha acelerado la depuración

En cuanto la tabla y el punto final estuvieron listos, los ingenieros de promociones empezaron a utilizarlos durante sus rotaciones de guardia. Una situación especialmente útil fue cuando se diseñó una promoción con un artículo específico, como obtener X de descuento al comprar Y artículo. Un operador ayudó a configurar la promoción para un comerciante que quería vender más bebidas enlatadas en su tienda, pero el código de promoción no funcionaba como se esperaba. La causa principal era que la lista de inventario de artículos en DoorDash no es coherente. Por ejemplo, el mismo refresco exacto en una tienda de comestibles y una tienda de conveniencia puede tener diferentes identificaciones de artículos. En este caso, la promoción pedía específicamente un refresco con el ID de artículo A, cuando el comerciante tenía un refresco con el ID de artículo B en su tienda. Esta discrepancia en el ID de artículo se identificó rápidamente cuando un promotor realizó un pedido utilizando el código de promoción en cuestión con la lata de refresco en el carrito. 

Esto ha supuesto un gran avance para el flujo de trabajo del equipo, y tiene potencial para tener un gran impacto más allá del final de las prácticas.

Ampliación de Kubernetes Horizontal Pod Autoscaler

Por Jianna Liu

DoorDash utiliza Kubernetes para ejecutar cargas de trabajo de microservicios. La mayoría de los microservicios de nuestro sistema se ejecutan en Kubernetes y se gestionan mediante Deployments y Argo Rollouts. Los microservicios reciben un número determinado de pods a lo largo de su vida útil o tienen un número dinámico que depende de la utilización de la CPU cuando está activado el Autoescalado Horizontal de Pods (HPA). ¿Qué significa esto exactamente y cuál es el problema que intentamos resolver? 

Actualmente, para asignar un número dinámico de pods, los microservicios utilizan HPA para determinar cuántos pods se les asignan. HPA determinará este número de pods midiendo la utilización de CPU y/o memoria de este microservicio. Hay casos de uso que no son soportados por el autoescalado usando CPU. Por ejemplo, muchas cargas de trabajo utilizan load shedding. Load shedding significa que estas cargas de trabajo rechazarán el exceso de tráfico una vez que la carga de trabajo esté a punto de sobrecargarse. Por lo tanto, estas cargas de trabajo no verán demasiados picos de CPU, lo que significa que para ellos la CPU no será una métrica precisa para el autoescalado. 

Al no escalar con precisión, desperdiciamos recursos y tenemos más cargas de operaciones. En junio de 2022, gran parte de los costes de infraestructura en la nube de DoorDash procedían de los nodos EC2 de Kubernetes. Al introducir el autoescalado de métricas externas, estimamos que podemos evitar el desperdicio de recursos para cada microservicio.

Integramos KEDA, un framework de código abierto, en nuestro sistema para ayudarnos a autoescalar en una variedad de eventos a través de eventos definidos por el usuario. El impacto que buscamos es la reducción de costes para la empresa gracias a un menor desperdicio de recursos y una menor intervención manual de los desarrolladores.

Despliegue de un ScaledObject

Empecemos ejecutando un experimento rápido. Antes de empezar, por favor asegúrese de que hay un clúster Kubernetes disponible y KEDA está instalado en el clúster.

Crearemos el siguiente recurso ScaledObject para autoescalar la carga de trabajo php de ejemplo tomada del tutorial de Kubernetes HPA.

objetoescala.yaml

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cron-scaledobject
  namespace: default 
  labels:
    deploymentName: php-apache
spec:
  maxReplicaCount: 12
  minReplicaCount: 1
  scaleTargetRef:
    name: php-apache 
  triggers:
    - type: cron 
      metadata:
         timezone: America/Los_Angeles 
         start: 30 * * * *
         end: 45 * * * *
         desiredReplicas: "10"

Este archivo yaml creará un ScaledObject que autoescala el despliegue php-apache (especificado en .metadata.labels.deploymentName). Estamos usando un escalador Cron.

Alrededor de la marca 30, el recuento de despliegues debería aumentar a 10 y alrededor de la marca 45, el recuento de despliegues debería disminuir a uno, como se muestra en la Figura 1. 

¿Cómo funciona KEDA?

A continuación se muestra su arquitectura. Profundicemos un poco más.

1. En primer lugar, un usuario creará un ScaledObject, como se muestra en la figura 2. El controlador KEDA estará atento a la aparición de nuevos ScaledObjects. 
2. Si el caso de uso es escalar el pod de 0 a 1 o de 1 a 0, el controlador KEDA gestionará directamente las réplicas de despliegue. Si el caso de uso es escalar el pod de 1 a n o de n a 1, el controlador KEDA creará internamente un HPA de Kubernetes para gestionar el despliegue.
3. HPA leerá las métricas del servidor API de Kubernetes, que a su vez reenviará la solicitud al servidor de métricas KEDA. 
4. El servidor de métricas KEDA contiene los valores de todas las métricas de eventos, dependiendo del escalador que utilicemos. En el diagrama anterior, el servidor de métricas utiliza un escalador prometheus.

En la primera iteración, admitiremos el escalador de CPU , el escalador de Cron y el escalador de Prometheus. El escalador de CPU permitirá que KEDA tenga paridad de características con el actual autoescalado de HPA. El escalador Cron se autoescala a un número predefinido de réplicas en un periodo de tiempo predefinido. Este proceso proporciona un autoescalado proactivo, lo que permite a los microservicios anticiparse a las cargas pesadas y definir la asignación de pods para los periodos previstos de picos de tráfico. El escalador Prometheus se autoescala basándose en métricas externas de Chronosphere. Esto proporciona un autoescalado reactivo. Esperamos que el autoescalado proactivo mediante el escalador Cron pueda cubrir la mayoría de los casos de uso. Sin embargo, cuando el autoescalado proactivo no anticipe el tráfico correctamente, el autoescalado reactivo podrá ayudar.

¿Cómo pueden los promotores utilizar KEDA?

Internamente, utilizamos helm charts para desplegar servicios. Introduciremos un nuevo campo de autoescalado en el gráfico helm, donde hay tanto subparámetros predefinidos como flexibilidad para que los usuarios definan sus propios parámetros.

service:
 autoscaling:
   minReplicaCount: 10
   maxReplicaCount: 20
   enable: true
   metrics:
   - cpu:
       threshold: # 50
       type: # ‘Utilization/AverageValue’
   - cron:
       start: # 30 * * * *
       end: # 45 * * * * 
       desired: # “10”
   - qps:
       threshold: # 50
       service: # payment-service
       app: # web
   - external:
     - prometheus:
         threshold: # “200”
         query: # ‘’
         metricName: # unique_metric_name

Uno de los problemas que prevemos es que la gente podría introducir una consulta incorrecta por accidente, lo que provocaría un autoescalado impreciso. Por lo tanto, queremos ofrecer la posibilidad de tener métricas predefinidas como qps, así como dar a los usuarios la flexibilidad de definir. Aún no estamos seguros de qué consultas predefinidas queremos ofrecer exactamente, pero después de hablar con los desarrolladores, esperamos encontrar un patrón en una consulta común. Anticipamos que las consultas comunes serán QPS y el tamaño de la cola para los trabajadores de Kafka.

¿Cuáles son algunas métricas importantes?

Entre las métricas importantes que queremos tener en cuenta para proteger nuestra migración se incluyen las siguientes:

• keda_metrics_adapter_scaler_error_totals - Número total de errores encontrados en todos los escaladores.
• keda_metrics_adapter_scaled_object_errors - Número de errores que se han producido para cada objeto escalado.
• keda_metrics_adapter_scaler_errors - Número de errores que se han producido en cada escalador.
• keda_metrics_adapter_scaler_metrics_value - El valor actual para cada métrica del escalador que sería utilizado por el HPA en el cálculo de la media objetivo.

• go_threads - creados por el controlador KEDA, número de hilos creados
• go_gc_duration_seconds - creado por el controlador KEDA, pausa la duración de los ciclos de recogida de basura
• go_goroutines - creadas por el controlador KEDA, número de goroutines que existen actualmente
• controller_runtime_reconcile_errors_total - creado por controlador KEDA, número total de conciliaciones por controlador 

• workqueue_adds_total{name=”horizontalpodautoscaler”} - created by kubernetes controller manager, total number of adds handled by workqueue: 
• workqueue_duration_seconds_bucket{name="horizontalpodautoscaler"} - creado por el gestor de controladores kubernetes, el tiempo de procesamiento de un elemento de la cola de trabajo
• workqueue_depth - creado por el gestor del controlador kubernetes, profundidad actual de la cola de trabajo
• apiserver_request_terminations_total - creado por el apiserver de kubernetes, número de peticiones que el apiserver ha terminado en defensa propia 

¿Cómo es el éxito?

El éxito se ve como la migración completa de los microservicios que actualmente utilizan la interfaz antigua a la nueva interfaz y la incorporación de la mayoría de los servicios a la autoescalabilidad. 

Esperamos que nuestro impacto suponga una reducción de costes para la empresa gracias a un menor despilfarro de recursos y una menor intervención manual de los desarrolladores.

Creación de una nueva infraestructura de herramientas internas para mejorar la experiencia de atención al cliente de DoorDash

Por Michael Yu

Como muchas empresas, DoorDash utiliza una variedad de métodos para autenticar una cuenta. Para mejorar la experiencia del cliente, queremos que este proceso sea lo menos doloroso posible. Los métodos de autenticación más comunes incluyen la autenticación de dos factores, las notificaciones push y los mensajes SMS.

Los correos electrónicos también se utilizan habitualmente para la autenticación multifactor, pero a veces los usuarios no pueden recibir correos electrónicos de autenticación. Al no recibirlos, los usuarios no pueden realizar acciones importantes como iniciar sesión, restablecer la contraseña o crear una cuenta nueva. En este artículo hablaremos del impacto que esto tiene en la experiencia del usuario y de cómo hemos creado herramientas internas para resolver el problema. 

Puntos débiles de la atención al cliente 

Un usuario que no puede recibir correos electrónicos de autenticación de dos factores naturalmente se pondrá en contacto con el equipo de soporte de DoorDash. Sin embargo, el equipo de soporte no tiene la capacidad de cambiar las preferencias de suscripción de correo electrónico. Los tickets que no pueden ser gestionados por el equipo de soporte se reenvían a los ingenieros de guardia, lo que puede llevar algún tiempo en resolverse y consumir un valioso tiempo de ingeniería. Para reducir la carga de trabajo diaria del equipo de guardia de Core Platform, hemos creado nuevas herramientas que ayudan a resolver este problema tan común. 

Creación de nuevas herramientas internas 

Como solución a este problema de verificación del correo electrónico, hemos creado una nueva herramienta interna para ampliar los permisos del equipo de soporte para ver y actualizar las suscripciones de correo electrónico sin la ayuda del equipo de ingeniería. Esta herramienta aliviará los problemas anteriores, ya que aumentará la cobertura del equipo de soporte de este tipo de tickets, reducirá el tiempo de respuesta y reducirá la carga de trabajo de guardia del equipo de la plataforma central. Dicha herramienta, que se representa en la Figura 1, debería permitir al usuario obtener preferencias de suscripción de correo electrónico, modificar dichas preferencias de suscripción, comprobar los permisos del usuario y ser fácil de navegar y utilizar.

Profundización arquitectónica

Para crear esta herramienta de permisos de correo electrónico, tuvimos que crear una nueva aplicación completa. 

En el lado del servidor, hemos creado un nuevo microservicio gRPC para albergar la lógica de la gestión de las preferencias de correo electrónico y la autorización de los usuarios. Este nuevo servicio servirá como sede de toda la futura gestión de preferencias de notificación, proporcionando la infraestructura inicial para facilitar el desarrollo de herramientas adicionales de gestión de preferencias para otros tipos de notificación además de los correos electrónicos, lo cual está previsto.

En el lado del cliente, elegimos que el servicio se ubicara con otras herramientas internas en Admin Gateway, una capa intermedia de backend para frontend (BFF) basada en Apollo GraphQL. DoorDash utiliza esta capa para aislar el desarrollo del backend del front-end, así como para agregar, procesar y reenviar las solicitudes del cliente a los servicios internos. Aquí, en Admin Gateway, hemos añadido una nueva página de herramientas de respuesta utilizando React que se integra con la capa intermedia BFF para comunicarse con el microservicio del lado del servidor.

Estos detalles de diseño pueden verse en la figura 2.

Impacto de nuestra solución 

En total, los tickets de soporte de suscripción por correo electrónico representan ~60% de todos los tickets recibidos en julio de 2022, constituyendo una mayoría de tickets para el equipo de Core Platform. La creación de esta herramienta reducirá significativamente el número de tickets que saturan constantemente el canal de Core Platform, aumentando la productividad de las guardias al eliminar estas numerosas interrupciones diarias. 

Además, estos tickets no sólo son una molestia para el equipo de ingeniería, sino también para el equipo de soporte y el cliente. Para el cliente, el problema puede tardar varios días en resolverse, dependiendo de cuándo pueda atenderlo el ingeniero de guardia. En cuanto a la experiencia del operador, el equipo de asistencia a menudo tiene que ponerse en contacto con varios equipos diferentes antes de encontrar una solución a esas incidencias. Al eliminar al equipo de ingeniería del proceso, podemos aumentar el tiempo de respuesta del cliente de unos pocos días al instante en que el cliente se pone en contacto con el equipo de soporte, mejorando tanto la experiencia del cliente como la del operador. 

Creación de banners de notificación extensibles en todas las páginas

Por Xiaochuan Xu

La función de notificación es una de las más importantes de la aplicación de DoorDash. No solo ayuda a los usuarios a seguir el estado de sus pedidos, sino que también les informa de las mejores ofertas de su zona. Sin embargo, millones de usuarios no se han suscrito a las notificaciones push de marketing, lo que les da menos oportunidades de disfrutar de las ventajas que ofrece DoorDash. 

Para construir un banner de notificaciones, como el que se muestra en la Figura 1, necesitábamos una forma de hacerlo extensible, de modo que pudiera añadirse fácilmente a todas las páginas en poco tiempo. Aunque construir banners es relativamente fácil, hacerlos extensibles es todo un reto porque, por un lado, estos banners son similares, ya que todos comparten las mismas preferencias de notificación de los usuarios, y por otro, cada uno de ellos necesita tener un experimento independiente y una bandera de características, para que la analítica pueda monitorizar la efectividad de cada banner. Ante estos retos, hemos creado una herramienta de backend que nos permita crear banners extensibles con mayor facilidad. Gracias a esta nueva solución, podemos ampliar fácilmente los banners de notificación en otras páginas y conseguir más suscriptores de marketing push con mayor rapidez en el futuro.

Dificultades técnicas para añadir un nuevo banner de notificación

Añadir un nuevo banner de notificación en una página concreta puede no ser una tarea difícil, pero crear una forma extensible de añadir un nuevo banner en diferentes páginas es complicado. Por un lado, nos gustaría evitar las llamadas repetidas para obtener las preferencias de notificación de los usuarios, y reutilizar la información para todos los banners. Esto puede reducir en gran medida la carga del servicio posterior que proporciona las preferencias de los usuarios. Además, nos gustaría ejercer un control detallado en cada pancarta para la configuración del experimento y los indicadores de características. Esta condición aparentemente contradictoria añade una dificultad adicional a la implementación. Si juntamos a la fuerza todos estos requisitos, los códigos resultantes serán menos mantenibles, menos legibles y más largos. Desafortunadamente, la implementación anterior tomó el camino más obvio, combinando estos requisitos acoplados. Y lo que es peor, la situación se deteriorará a medida que se añadan más banners de notificación en diferentes páginas.

Creación de una solución extensible de banners de notificación

Para construir una solución extensible de banners de notificación, tuvimos que seguir los siguientes pasos: 

1. Revisar la solución heredada, concretamente necesitábamos averiguar el punto final existente, que filtrará y devolverá las pancartas necesarias a un consumidor.
2. Garantizar que la información sobre las preferencias de los usuarios se reutiliza en diferentes pancartas.
3. Diseñar nuestra propia solución que se adapte a la arquitectura del punto final existente, ya que puede proporcionarnos un control detallado de las pancartas individuales.

Revisión de la solución heredada  

Para construir un banner de notificación extensible, lo primero que hicimos fue dar un paso atrás y revisar cómo funciona el punto final (getBannersV2) para devolver esos banners, tal y como se muestra en la Figura 2. En getBannersV2 existe un proceso de filtrado que, en primer lugar, recupera todas las campañas relevantes (para simplificar, utilizaremos "banners" y "campañas" indistintamente) para un consumidor. A continuación, se generarán los EligibilityMetaData, que son los metadatos que almacenan toda la información necesaria para filtrar posteriormente las campañas no válidas. A continuación, el filtro comprobará una campaña basándose en una serie de criterios, comparando cada uno de ellos con los EligibilityMetaData, de modo que se filtrarán las campañas no elegibles y sólo se devolverán al lado del cliente los banners válidos para una solicitud concreta. 

El proceso de filtrado original es elegante y eficaz, ya que disocia el proceso de obtención de información sobre los usuarios (EligibilityMetadata) del paso de comprobación de la información. Sin embargo, la implementación anterior de los banners de notificación no respeta este proceso. En su lugar, añadió una lógica ad hoc para obtener las preferencias de notificación de los usuarios y, a continuación, comprobarlas para filtrar las pancartas relacionadas con la notificación (Figura 2). Esta solución no resuelve los problemas técnicos mencionados y empeora cada vez que se añade un nuevo banner.

Garantizar que los datos de preferencias de notificación de los usuarios sean reutilizables en todas las pancartas.

Después de revisar la arquitectura de getBannersV2(), nos dimos cuenta de que la esencia de la solución es reutilizar la tubería de filtrado original, lo que significa que debemos añadir nuestra propia lógica en el lugar correcto dentro de la tubería.

Para los datos de preferencia de notificación de los usuarios, podemos obtenerlos una vez y reutilizarlos varias veces para diferentes pancartas. Por lo tanto, durante la etapa de generación de EligibilityMetadata , debemos hacer una llamada gRPC externa a otro servicio en DoorDash, para obtener los datos de preferencia de notificación de los usuarios y almacenarlos en EligibilityMetadata para su uso posterior.

Para utilizar realmente EligibilityMetadata, debemos asegurarnos de que esta campaña (banner) tiene un nuevo criterio de usuario correspondiente relativo a las preferencias de notificación de los usuarios, como se muestra en la Figura 3 . Para conseguirlo, necesitamos construir un nuevo userCriterion a través del protobuf, y asignar este criterio al banner de notificación, que indica que queremos que este banner se compruebe con las preferencias de notificación de un usuario en particular. El filtro ejecutará automáticamente todo el proceso por nosotros.

Control detallado de las pancartas individuales

Una de las ventajas de adoptar el pipeline es que nos facilita la gestión de los experimentos de banners individuales con una interfaz de usuario, el gestor de campañas. Con ello, no necesitamos códigos adicionales para configurar los experimentos de un banner. En su lugar, todo lo que tenemos que hacer es configurar el experimento para un banner concreto en el gestor de campañas. Esto nos ayuda a añadir un nuevo banner más rápidamente, ya que los nuevos banners ya no requieren ningún cambio de código con respecto a los experimentos. 

Ventajas de la nueva aplicación

Con la nueva implementación del banner de notificaciones, puede ampliarse fácil y rápidamente a otras páginas. En comparación con la implementación inicial, la lógica para filtrar los banners en función de las preferencias de notificación de los usuarios es la misma y puede reutilizarse en los banners de notificación de distintas páginas. Además, no necesitaremos programar experimentos en los códigos. En cambio, al adoptar el pipeline, los experimentos a nivel de campaña se soportan de forma natural. En comparación con el uso de tiempo de ejecución para cambiar mediante programación la configuración del experimento, ahora podemos configurar el experimento a través de la plataforma de experimentos interna de DoorDash - Valores dinámicos. En general, la refactorización puede reducir el tiempo de despliegue del banner de notificación de unas horas a sólo unos minutos, ahorrando en gran medida los esfuerzos del ingeniero. 

Impacto

Este proyecto ha tenido una influencia positiva en la ingeniería, pero quizá lo más importante es que también está generando un impacto positivo en el negocio. Tras la refactorización, el banner de notificación de la página Offer Hub se ha ampliado a todos los usuarios de iOS, lo que supone millones de usuarios objetivo. Esperamos un aumento anual de cientos de miles de suscriptores de marketing push gracias a esta función.