Global-Scale React: Arquitectura para Localización, Multi-Tenancy y Mercados Dinámicos

Hola, gracias por unirte a mi sesión. Hoy compartiré lecciones de la construcción y escalado de aplicaciones globales de React. Lección vinculada, somos como una fiesta de 13.4 Go. Esta charla trata sobre algo con lo que muchos equipos eventualmente se encuentran. Es decir, tu aplicación de React que comienza como un producto único para un solo mercado, pero con el tiempo, el negocio crece internacionalmente y de repente tu front-end se vuelve responsable de manejar monedas, cumplimiento, localización, personalización de inquilinos, diferencias de características regionales, y luego la complejidad operativa.

En ese punto, la arquitectura del front-end deja de ser solo una interfaz de usuario. Se convierte en parte de la arquitectura del negocio en sí misma. Así que hoy, recorreré los patrones, las compensaciones y las decisiones importantes que nos ayudaron a escalar React para un mercado global sin colapsar en esa complejidad. Uno de los mayores conceptos erróneos en la ingeniería de front-end es pensar que la globalización simplemente significa agregar traducciones. En realidad, una vez que tu producto se expande internacionalmente, casi todas las partes de tu aplicación necesitan cambiar. Porque diferentes regiones tienen diferentes proveedores de pago, diferentes sistemas de impuestos. A veces viene con diferentes reglas de cumplimiento, y también necesitas tener diferentes disponibilidades de características, incluso diferentes expectativas en torno a la experiencia del usuario.

Por ejemplo, una experiencia de aplicación tecnológica en el Reino Unido puede comportarse de manera completamente diferente a una en Nigeria o Canadá. Lo que descubrimos muy temprano en nuestro producto fue que escalar globalmente significa que nuestra arquitectura de front-end comienza a reflejar directamente la complejidad del negocio. Tu enrutamiento de componentes, despliegue, estrategias de renderizado sistemas de configuración y herramientas operativas se ven afectados por la variabilidad del mercado. Antes de avanzar más, permíteme darte un contexto sobre lo que estamos construyendo. Nuestro producto es una plataforma de viajes global que incluye vuelos, hoteles, experiencias, infraestructura, operaciones multirregionales. Esto se vuelve muy grande porque múltiples verticales están operando al mismo tiempo a escala global.

Si miras este contexto en comparación con tu producto, significa que nuestro front-end de React tiene arquitecturas duales porque algunos de nuestros productos están ejecutándose en Next, y eso está ejecutándose en Plain React. A veces, si miras la forma en que Micro front-end funciona, no funciona en todos los frameworks debido a algunos problemas de compatibilidad, lo que significa que necesitamos ejecutar arquitecturas duales cuando se trata de nuestro front-end. Necesitamos proporcionar soporte para infraestructura multi-moneda, multi-inquilino, experiencias conscientes de la región, y luego despliegues dinámicos de características.

Servimos a múltiples negocios y segmentos de clientes. También necesitamos equilibrar la consistencia con la flexibilidad. Las decisiones arquitectónicas que estamos tomando están fuertemente impulsadas por realidades operativas. Muy bien, ese es un contexto sobre lo que estamos construyendo.

por realidades operativas. Muy bien, ese es un contexto sobre lo que estamos construyendo. Ahora, ¿qué podría romperse a escala global? A medida que la plataforma se expande a múltiples regiones, surgirían varios problemas. Así que los dividí en dos.

Uno son problemas técnicos, y el otro es problemas organizacionales. Hablaremos de eso más tarde. Ahora, tomemos el problema técnico. Ahora, hay muchas cosas de las que necesitas empezar a llevar la cuenta. La primera es que necesitas llevar la cuenta de no incrustar la lógica de negocio directamente en tu componente.

Otra cosa que podría suceder es que la escalabilidad podría convertirse en un problema, que a menudo aparece gradualmente. Por ejemplo, horas de picos de usuarios, IA, tiempo de despliegue de usuarios, y similares. Así que parte del problema técnico es que estás codificando alguna lógica de mercado en tus componentes. A veces, estás trayendo despliegues específicos por región porque quieres que esta característica esté disponible en el Reino Unido y esta esté disponible en los mercados de EE.UU.

Ahora, volviendo a los problemas organizacionales. ¿Qué podría también romper nuestra escala? Ahora, tienes múltiples equipos trabajando en múltiples características, y esto necesita enviarse globalmente. Ahora, habrá algunos desafíos donde los equipos comenzarán a interferir en los lanzamientos de los demás si no se tiene cuidado o no se manejan adecuadamente. Luego, ciclos de implementación lentos, dificultad en probar el comportamiento impulsado por el mercado si no tienes personas presentes en ese mercado. A veces, esto podría causar problemas. Y la duplicación de configuraciones, este es otro desafío que necesitas tener en cuenta que podría romperse a escala global.

Así que agregar más mercados aumentó la complejidad exponencialmente. Necesitas tener en cuenta eso. La traducción es solo una pequeña parte de la localización. La localización de la vista afecta el formato de moneda, el manejo de datos, tus impuestos, el comportamiento de cumplimiento, la priorización de contenido, las reglas comerciales regionales. Por ejemplo, un flujo de pago en el Reino Unido puede usar el IVA como cálculos y probablemente esforzarse por el procesamiento de pagos, mientras que un mercado de EE.UU. o un mercado canadiense no usará el IVA, podría usar algo como el HST o cuál es el código fiscal en ese mercado.

Así que eso también necesita suceder o ser impulsado dinámicamente. Entonces, a veces, el orden en el que los productos aparecen para los usuarios en diferentes mercados necesita ser diferente, lo que significa que la localización afecta tus APIs, tu enrutamiento, tu renderizado, tu gestión de estado, tus características, y a veces tu lógica de negocio. Así que la localización se convierte en un patrón arquitectónico de todo el sistema. Una cosa que notamos rápidamente fue que los mercados se comportan de manera diferente, no solo visualmente, sino operativamente. Algunos proveedores de pago están disponibles en ciertas regiones, y algunas características necesitan pasar por revisión regulatoria. Y a veces, algunas integraciones solo existen en mercados específicos. Por ejemplo, puede que necesites proporcionar la característica de billetera para el mercado americano, y luego para el mercado nigeriano o el mercado africano, podrías eliminar la característica de billetera.

En lugar de construir una aplicación estática, necesitas construir una plataforma adaptativa que sea capaz de cambiar su comportamiento dinámicamente según el contexto del mercado. Ese cambio de mentalidad cambió por completo cómo abordamos la arquitectura del front-end. Ahora, en lugar de preguntar qué deberían hacer estos componentes, comenzamos a preguntar sobre algunas características, ¿qué permite la configuración actual del mercado? Ese pequeño cambio de mentalidad lo cambió todo. Ahora, las características podrían habilitarse dinámicamente, los proveedores de pago se volvieron configurables, la incorporación al mercado se hizo más rápida y nuestro despliegue se volvió más seguro.

Entonces, hablando de configuración, esencialmente se convierte en el plano de control para el front-end. De la misma manera que tienes tu plano de control para tu Kubernetes, así es como ahora configuramos nuestra configuración para deshacer el despliegue global. Lo importante es que redujo el caos de renderizado condicional que podría ocurrir dramáticamente. Así que eso nos ayudó a evitarlo. A escala global, el despliegue y las liberaciones ya no son lo mismo. Las feature flags se volvieron muy críticas para nosotros, y puedes usarlas para habilitar capacidades específicas que pueden usar retake.

Esto se puede usar para habilitar capacidades específicas del mercado, es decir, implementar características. Luego, también puedes usar esto para ejecutar experimentos de manera segura. También puedes usar esto para deshabilitar características inestables al instante. Ahora, esto se volvió muy esencial para nosotros porque diferentes regiones evolucionaron a diferentes velocidades. Algunos mercados estaban listos para la infraestructura de billetera, otros aún estaban en proceso de revisión de cumplimiento. Así que tener feature flags a escala te ayuda a gestionar esto de manera eficiente. Te ayuda a gestionar esto de manera eficiente. Ahora, las feature flags nos dan flexibilidad operativa sin forzar el redeployment cada vez. El enrutamiento también se convirtió en parte de nuestra estrategia de plataforma. Necesitábamos URLs conscientes del lugar. Necesitamos tener paquetes conscientes del mercado.

También necesitamos optimizar nuestro CDN para cada uno de esos mercados. Y luego también necesitamos asegurarnos de que nuestro SEO sea consistente para diferentes mercados. Y lo otro que también aseguramos es que tenga sentido es una mejor capacidad de descubrimiento para diferentes mercados. Si estás buscando un producto en el mercado africano, verás un producto, pero en un campo diferente, y esto sucede dinámicamente. Ahora, el enrutamiento consciente de la región también mejoró la separación de preocupaciones operativas. Diferentes regiones podrían evolucionar independientemente mientras mantienen una plataforma de front-end compartida. Por eso el micro front-end fue muy asombroso para nosotros.

También aprovechamos las estrategias de enrutamiento a nivel de borde para reducir la latencia y mejorar el rendimiento más cerca de los usuarios. Así que esto es muy importante para nuestro desarrollo. A escala, la observabilidad del front-end se vuelve absolutamente esencial. Cuando algo se rompe globalmente, necesitas respuestas de inmediato. Así que, dentro de su visibilidad en características específicas de la región, problemas específicos de inquilinos, el impacto de las feature flags en el rendimiento, y también necesitamos tomar nota de regresiones e inestabilidad de integración. Así que, aquí es donde herramientas como OpenTelemetry, Sentry, y luego Structured Logging se volvieron fundamentales. Una lección importante es que si no puedes observar el front-end globalmente, entonces significa que no puedes escalar el front-end globalmente.

Antes de introducir complejidad, nos preguntamos, ¿qué cambia por mercado? También preguntamos, ¿qué cambia por inquilinos? ¿Qué debe permanecer consistente? ¿Qué pertenece a la configuración? ¿Qué pertenece al código? ¿Qué podemos aislar?