Cómo se benefició iFood de la arquitectura orientada a eventos para modernizar su middleware financiero

Solución propuesta

Para abordar los problemas anteriores, iFood contó con el apoyo del equipo de “Professional Services” (Servicios Profesionales) de AWS. Éste equipo, utilizando la técnica del “working backwards” o trabajando al revés desde la necesidad del cliente, analiza los requerimientos reales, tangibles y accionables del equipo y orienta en cuál debe ser el camino a seguir diseñando una solución óptima para satisfacer esa necesidad.

Tras este trabajo, iFood y AWS entendieron que para abordar y resolver los problemas de la plataforma, sería necesario un cambio de paradigma, pasando de una arquitectura monolítica a una arquitectura de microservicios orientada a eventos. La primera etapa consistió en la ejecución de talleres  immersivos    o de “Event Storming”, para que los equipos de ingeniería y producto pudieran construir juntos el DDD (Domain Driven Design) de la plataforma. El objetivo era alinear a todas las partes interesadas garantizando un flujo de comunicación eficiente.  Al profundizar, se descubrió la esencia de cada dominio empresarial y, por lo tanto, se definieron contextos acotados precisos. Durante estos talleres, también fue posible identificar procesos empresariales críticos, entidades y agregaciones y normalizar todo el flujo de eventos para mejorar la comunicación y la colaboración entre los equipos.

Gracias a las ideas descubiertas en estas sesiones,  se identificaron tres dominios comerciales principales dentro del monolito existente. Basado en éstos, se tomó la decisión de descomponerlo en tres microservicios distintos

1. Gestión de datos maestros
2. Provisión
3. Solicitud

Cada servicio es el único responsable de su dominio empresarial vertical y se comunica entre sí a través de una arquitectura orientada a eventos.

Además, se planteó la necesidad de crear una capa adicional en la arquitectura, un BFF (Backend for Frontend), que se encargue de interactuar con todos estos dominios, agregando datos de los múltiples microservicios para presentarlos de manera unificada a los consumidores de las API. También se determinó transformar las solicitudes sincrónicas en asincrónicas

Para habilitar esta nueva forma de comunicación entre la BFF y los microservicios, se adoptó Amazon EventBridge como enrutador de eventos. Gracias a su simplicidad, escalabilidad, alta disponibilidad y resiliencia; se convirtió en la pieza principal de la estructura de comunicación. Al conectar los microservicios a EventBridge, se creó una coreografía entre los mismos, enviando eventos de un dominio a otro y abstrayendo a los productores de los consumidores dando autonomía a los dominios.

Para garantizar la total autonomía y escalabilidad de cada microservicio, también se decidió descomponer la base de datos, de modo que cada microservicio tenga su propia base de datos. Este enfoque, además de evitar que se produzcan cuellos de botella cuando muchos servicios acceden a la misma base de datos; también garantiza que cada microservicio pueda escalarse de forma independiente y que un equipo pueda gestionarlo, soportarlo y desarrollarlo de forma autónoma.

Figura 2 — Nueva arquitectura DBY orientada a eventos

Amazon EventBridge como principal bús de eventos

Dediquemos un momento a analizar las ventajas de Amazon EventBridge y a entender por qué se eligió como el principal bús para eventos de DBY.

DBY necesitaba un bus de eventos que pudiera filtrar y enrutar los eventos de forma performante, con alta disponibilidad y escalable. EventBridge era la selección más adecuada dados estos requerimientos ya que es un servicio regionalizado, sin servidor, con alta disponibilidad y escalabilidad nativa y que puede satisfacer una gran cantidad de solicitudes por segundo con una latencia muy baja. Además, el modelo de facturación de EventBridge es uno de pago por uso por lo cual sólo pagas por los eventos enviados. Esto resulta en optimización de costos ya que no es necesario pagar por los recursos inactivos.

EventBridge tiene las siguientes funciones que añaden también más valor:

Reglas y objetivos: EventBridge le permite definir reglas basadas en estándares. Estas reglas se pueden aplicar a cualquier ámbito del evento, de modo que cada evento se filtre y se dirija a diferentes destinos de forma individual, desvinculando a los productores de los consumidores.

Integración con CloudWatch: permite que todos los eventos se registren por completo, lo que facilita una supervisión activa y reactiva mediante alarmas.

EventBridge Pipes: con Pipes puede consumir eventos directamente de servicios como SQS, DynamoDB, Kinesis y Kafka, sin necesidad de escribir código. También permite filtrar y transformar los eventos antes de entregarlos al destino.

Archivar y reproducir: con Archive puedes almacenar todos los eventos que pasan por el bús o crear filtros para almacenar un patrón de eventos determinado. Con la reproducción, puedes volver a procesar todos los eventos que se almacenaron con reglas específicas que permiten volver a procesar los eventos en caso de fallas, incidentes o incluso por una necesidad empresarial puntual.

Un ejemplo del uso de EventBridge en la nueva plataforma DBY es cuando la interfaz consulta una lista de mercancía para el microservicio de suministro. Vea la secuencia de ejecución que transforma una solicitud sincrónica en una solicitud asincrónica y luego devuelve la solicitud inicial de forma sincrónica.

1. La interfaz hace una solicitud sincrónica para el BFF
2. El BFF envía un evento asincrónico a EventBridge:
   {    "eventType": "MaterialListRequested",    "companyCode": "12",    "functionalArea": "34}
3. EventBridge dirige el evento al backend responsable de acuerdo con el campo `eventType`e
4. El backend procesa la solicitud de forma asincrónica;
5. El BFF sondea el backend para obtener la respuesta actualizada;
6. El BFF devuelve la solicitud sincrónica inicial a la interfaz.

Es importante recordar que la nueva plataforma DBY necesitaba mantener la compatibilidad con otros sistemas antiguos, por lo que se incluyó la capa BFF para intercambiar solicitudes sincrónicas por solicitudes asincrónicas y viceversa.

Figura 3 — Diagrama de secuencia del flujo de solicitudes para el microservicio de suministro

Estrategia de migración e implementación

Para evitar tiempo de inactividad y la pérdida de integridad de los datos, se decidieron migrar los mismos a la nueva plataforma DBY de una sola vez durante un período de migración en el que la plataforma no esté en uso. Para decidir la forma de migración, se consideraron factores como las horas de uso de la plataforma, la cantidad de datos a migrar y la tecnología de bases de datos antes y después de la migración.
En el caso de la plataforma DBY, había una ventana de mantenimiento en la que no se accedía a la plataforma y la cantidad de datos a migrar cabía dentro de esa ventana. Otro factor importante es que la tecnología de base de datos utilizada por el monolito y la nueva plataforma era la misma. En ambas se utilizaba Postgres, por lo que no era necesario convertir los esquemas, solo la división de datos de una única base de datos a múltiples bases de datos separadas por un microservicio.

Se eligió a “Canary” para la estrategia de implementación. Esta estrategia permite lanzar la nueva versión de la plataforma a un pequeño porcentaje de usuarios, de modo que podamos monitorear e identificar rápidamente si se produce un problema, lo que también permite una acción de reversión rápida. Transcurrido un cierto periodo de tiempo y sin que se produjera ningún incidente, completamos la implementación llevando el 100% de la nueva versión al entorno de producción. Es importante destacar que, para tener una estrategia de implementación en Canary, es necesario contar con un proceso de CI/CD automatizado y bien estructurado, en el que se establezcan métricas para medir el éxito de la implementación, así como acciones automatizadas para completarla o revertirla.

Gracias a las estrategias de migración e implementación de datos con Canary, pudimos garantizar un intercambio seguro de la versión de la plataforma, pasando de la arquitectura de microservicios monolítica a la orientada a eventos.

Beneficios obtenidos por iFood

La modernización de la plataforma aportó importantes beneficios al equipo financiero de iFood. Anteriormente, tenían dificultades para que las nuevas funciones estuvieran disponibles rápidamente, lo que ponía en peligro el tiempo de comercialización. Tras la migración, el tiempo de desarrollo de las nuevas funciones se redujo de 1 mes a 1 semana. Con la distribución de los microservicios por dominios, los equipos tuvieron más autonomía y velocidad, y pudieron desarrollar su microservicio sin preocuparse por otras partes de la plataforma.

La transición a peticiones asincrónicas permitió a los equipos mejorar la experiencia del usuario final. Con la eliminación de muchas llamadas sincrónicas que aumentaban el acoplamiento entre los componentes, se produjo una mejora significativa en el rendimiento y la resiliencia. Las fallas en un servicio en particular ya no afectan a otros servicios; lo que permite una experiencia ininterrumpida para el cliente final. Además, la adopción de EventBridge permitió incluir fácilmente nuevas capacidades, como el uso de DLQ (Dead Letter Queue) y políticas de retención, garantizando que no se perdiera ningún evento si algún microservicio no funcionaba.

Es importante recordar que el uso del diseño basado en dominios contribuyó en gran medida a identificar de manera eficiente cuáles son los dominios comerciales, dándoles autonomía. Con límites bien definidos entre los dominios, los equipos ahora pueden trabajar de forma independiente, centrándose en sus áreas específicas de conocimiento.

Según los datos obtenidos tras la implementación de la nueva arquitectura, hubo un aumento en la disponibilidad de la plataforma en un 30%, una reducción en el MTTR (tiempo medio de recuperación) del 90% y una reducción en el tiempo de entrega de las nuevas funcionalidadesdel 50%.

Conclusión

A jornada de modernização é uma jornada contínua e os times do iFood contam com o poder dos serviços da AWS, bem como uso de boas práticas para continuar a otimizar duas aplicações. Abraçando a inovação e adotando modernas abordagens de arquitetura estarão bem equipados para atender a crescente demanda e se adaptarem às futuras necessidades de negócio. A modernização da plataforma DBY é um exemplo da importancia de se abrir a mudanças se beneficiando de serviços que facilitam e aceleram a implementação de soluções modernas e robustas.

Este artículo fue traducido del Blog de AWS en Portugués.

Sobre os autores

Ricardo Marques es un arquitecto de soluciones sénior en AWS, con más de 15 años de experiencia en desarrollo de software, arquitecturas de soluciones escalables, nativas en la nube, orientación a eventos y. Trabaja apoyando a los clientes nativos digitales, ayudándolos en su viaje a la nube. También es profesor de MBA en arquitecturas de nube.

https://www.linkedin.com/in/ricardo-marques-45846425

Abbas Zahid es un arquitecto de aplicaciones sénior en AWS con más de 11 años de experiencia en la industria de la nube. A lo largo de su carrera, se centró en el desarrollo y la arquitectura de aplicaciones nativas de la nube en diferentes plataformas de nube, ofreciendo productos seguros, escalables y resilientes. Actualmente, ayuda a los clientes a modernizar sus aplicaciones mediante diversos estilos arquitectónicos y a aprovechar las ventajas de la nube disponibles en AWS.

https://www.linkedin.com/in/abbas-zahid-50b50a50

Revisor

Manuel Ortiz Bey es un arquitecto de soluciones sénior en AWS para el segmento de empresas nativas en la nube con 20 años de experiencia en ingeniería de software, especialmente en el desarrollo de aplicaciones con arquitecturas modernas. A lo largo de su carrera ha trabajado en empresas de tecnología, banca y consultoría; además de haber co-fundado distintos startups tecnológicos exitosos. Actualmente, además de ayudar a sus clientes en su viaje en la nube de AWS, se encuentra especializándose en arquitecturas de microservicios en infraestructuras serverless. https://www.linkedin.com/in/manuelortizbey/