¿Cómo rediseñar un flujo de lectura de datos de pagos para lograr rendimientos de hasta 150 veces superiores?

En los últimos años, Airbnb migró la mayoría de sus servicios de back-end de un monolito a una arquitectura orientada a servicios (SOA). Esta arquitectura estándar de la industria brinda innumerables beneficios a una empresa que está a la escala de Airbnb; sin embargo, no está libre de desafíos. Con los datos dispersos en muchos servicios, es difícil brindar toda la información que los clientes necesitan de manera simple y eficaz, especialmente para dominios complejos como los pagos. A medida que Airbnb creció, este problema comenzó a surgir para muchas iniciativas nuevas, como las ganancias de los anfitriones, la generación de formularios de impuestos y las notificaciones de pago, todo lo cual requería que se leyeran los datos del sistema de pagos.

¿Cómo rediseño Airbnb la capa de lectura de datos de pagos unificados?. Esta capa de lectura se creó a la medida para reducir la fricción y la complejidad de las integraciones de los clientes, al tiempo que mejora en gran medida el rendimiento y la confiabilidad de las consultas. Con esta nueva arquitectura, lograron una experiencia muy optimizada para las comunidades anfitrionas e invitados, así como a los equipos internos en los dominios de confianza, cumplimiento y atención al cliente.

Evolución de la plataforma de pagos de Airbnb
Los pagos son una de las primeras funcionalidades de la aplicación de Airbnb. Payments Platform ha crecido y evolucionado enormemente, y continúa evolucionando a un ritmo aún más rápido dada la presencia global en expansión de la plataforma líder en alojamientos

Al igual que otras empresas, Airbnb comenzó su viaje con una arquitectura de aplicación monolítica. Dado que el conjunto de funciones era inicialmente limitado, tanto los flujos de pago de escritura como de lectura eran “relativamente” simples.

Como era de esperar, esta arquitectura no pudo escalar bien con el rápido crecimiento y expansión de la empresa. Los pagos, junto con la mayoría de las otras partes de la tecnología, comenzaron a migrar a la arquitectura SOA. Esto trajo una revisión significativa de la arquitectura existente y proporcionó muchas ventajas, que incluyen:

• Límites claros entre los diferentes servicios, lo que permitió una mejor propiedad del dominio e iteraciones más rápidas.
• Los datos se separaron en dominios en una forma muy normalizada, lo que resultó en una mejor corrección y consistencia.

La nueva arquitectura presenta nuevos desafíos
Payments SOA proporcionó un sistema de pagos más resistente, escalable y mantenible. Durante esta larga y compleja migración, la corrección del sistema fue la máxima prioridad para Airbnb. Los datos se normalizaron y dispersaron en muchos dominios de pagos de acuerdo con las responsabilidades de cada equipo. Esta subdivisión del trabajo tuvo un efecto secundario importante: las capas de presentación ahora a menudo necesitaban integrarse con múltiples servicios de pago para obtener todos los datos requeridos.

Las superficies relacionadas con los pagos de Airbnb y las ganancias muestran una variedad de detalles que incluyen tarifas, fechas de transacciones, monedas, montos y ganancias totales. Después de la migración de SOA, analizar varios servicios demandaba leer incluso más tablas que antes de la migración para obtener toda la información solicitada. Naturalmente, esta base presentó desafíos cuando requerían agregar nuevas superficies con datos de pagos o cuando necesitaban ampliar las superficies existentes para proporcionar detalles adicionales.

Una nueva capa de lectura de datos unificados de pagos
Para lograr ambiciosos objetivos de pagos, había que repensar cómo los clientes se integran con la plataforma de pagos.

Puntos de entrada unificados
La primera tarea fue unificar los puntos de entrada de lectura de datos de pagos. Para lograr esto, utilizaron Viaduct, la red de servicios orientada a datos de Airbnb, donde los clientes consultan la “entidad” en lugar de tener que identificar docenas de servicios y sus API. Esta nueva arquitectura requería que los clientes se preocuparan solo por la entidad de datos necesaria en lugar de tener que comunicarse con servicios de pago individuales.

Entidades de datos unificados de nivel superior
Tener un único punto de entrada es un buen comienzo, pero no resuelve toda la complejidad. En pagos, se manejan más de 100 modelos de datos y se requiere una buena cantidad de conocimiento del dominio para comprender claramente sus responsabilidades. Si solo se exponen todos estos modelos desde un único punto de entrada, aún se requeriría demasiado contexto para los ingenieros del cliente.

Los principios para la nueva arquitectura fueron los siguientes:

• Simple: diseño para ingenieros de impagos y uso de terminología común.
• Extensible: mantenga un acoplamiento flexible con el esquema de almacenamiento y encapsule conceptos para protegerse de cambios internos de pagos al tiempo que permite iteraciones rápidas.
• Rico: oculta la complejidad pero no los datos. Si los clientes necesitan obtener datos, deberían poder encontrarlos en una de las entidades.

Migrar y Elevar: Historial de transacciones
La primera superficie de prueba para la nueva arquitectura de lectura de datos unificados fue Transaction History (TH). Los anfitriones de la plataforma usan la página Historial de transacciones para ver sus pagos pasados ​​y futuros junto con las métricas de ganancias de nivel superior (por ejemplo, el monto total pagado).

Desde el punto de vista técnico, este fue uno de los flujos de pagos más complejos. Se requerían muchos detalles diferentes y los datos provenían de más de 10 tablas de pagos. Esto había causado problemas en el pasado, incluidos tiempos de espera, tiempos de carga lentos, tiempo de inactividad debido a dependencias estrictas y velocidad de iteración lenta como resultado de implementaciones complejas. Durante el diseño técnico inicial para la migración de TH desde el monolito de Airbnb a SOA, se decidió rediseñar este flujo en lugar de aplicar curitas. Esto ayudó a garantizar el éxito a largo plazo y brindar la mejor experiencia posible a la comunidad anfitriona.

Este caso de uso se ajustó perfectamente a la capa de lectura unificada. Utilizando los datos de TH como punto de partida, crearon una nueva API y una entidad de alto nivel para atender todos los casos de uso de lectura de datos de dominios similares.

Después de bloquear la entidad y su esquema, comenzaron a desnormalizar los datos. Gracias al marco de almacenamiento optimizado para lectura, pudieron desnormalizar todos los datos de más de 10 tablas en un par de índices de Elasticsearch. No solo redujeron en gran medida los puntos de contacto de la consulta, sino que también lograron paginar y agregar de manera mucho más eficiente al aprovechar la capa de almacenamiento, en lugar de realizar las mismas operaciones en la capa de aplicación. Después de casi dos años de trabajo, migraron el 100% del tráfico y lograron mejoras de latencia de hasta 150 veces, al tiempo que mejoraron la confiabilidad del flujo de ~96 % a 99,9+%.

Fuente:  https://www.randstad.cl/