Qué es White Label
Introducción al proyecto White Label: qué es, por qué existe, qué problema resuelve y cómo está organizado técnicamente.
El proyecto
White Label es la plataforma tecnológica que unifica el ecommerce de las marcas del grupo Cencosud en Latinoamérica. El proyecto nace con un objetivo claro: construir una única base tecnológica que soporte múltiples marcas y mercados, en lugar de mantener sistemas independientes para cada una.
Somos un sistema white-label multi-tenant: la misma plataforma corre para distintas marcas, cada una con su propia configuración, proveedores y particularidades de negocio, pero compartiendo la misma infraestructura y base de código.
El problema que resuelve
Cencosud opera múltiples marcas de retail en distintos países. Históricamente, cada marca tenía su propio equipo de tecnología, su propia implementación y sus propias decisiones técnicas.
Cuando el grupo decide unificar, absorbe esos equipos y esas implementaciones. El resultado es una plataforma que hereda años de decisiones heterogéneas: distintos proveedores, distintos modelos de datos, distintas formas de resolver los mismos problemas.
White Label existe para resolver eso: una sola plataforma, un solo estándar, múltiples marcas.
Qué hacemos técnicamente
Somos una capa de orquestación y adaptación. La lógica de negocio principal vive en sistemas externos: VTEX maneja el catálogo, precios y checkout; Constructor maneja el search; otros proveedores varían según el mercado. Nuestro trabajo es coordinar esos sistemas y exponer una API unificada a la app móvil de cada marca la cuál también es WL y consume nuestro sistema.
En concreto:
- Exponemos la funcionalidad de los providers a través de una API única para que las apps no dependan de qué proveedor corre detrás de cada mercado.
- Gestionamos los datos propios del usuario: perfil, direcciones, preferencias, sesión, carrito y loyalty.
- Coordinamos entre múltiples sistemas para construir respuestas coherentes, aplicando las reglas y particularidades de cada marca en el proceso.
- Orquestamos flujos que involucran más de un sistema externo, como un checkout que toca VTEX, un motor de promociones y un programa de loyalty al mismo tiempo.
Cómo está organizado el sistema
El sistema está compuesto por microservicios organizados en dominios funcionales. Cada dominio representa una capacidad clara dentro de la plataforma, con sus propios datos, su propia lógica y su propio ciclo de vida.
Los dominios que existen hoy son:
- Identity & Access: autenticación, sesiones y credenciales.
- Customer Profile: datos del cliente, términos y consentimientos.
- Customer Address: direcciones del usuario y sincronización con providers.
- Customer Preferences: preferencias dietarias, marketing y suscripciones.
- Cart: carrito de compras, items, mensajes y validación.
- Product Catalog & Search: búsqueda, discovery y detalle de productos.
- Promotions: motor de reglas para calcular y priorizar promociones.
- Loyalty: beneficios, cashback, ofertas y programas de fidelización.
- Geo & Stores: tiendas, cobertura geográfica y selección de sellers.
- Remote Config: sincronización de configuración desde sistemas externos.
El modelo ideal es un microservicio por dominio. Cuando un servicio concentra responsabilidades de varios dominios, es una señal de deuda técnica, no de diseño intencionado.
Multi-tenant: cómo soportamos varias marcas
Cada instancia del sistema corre configurada para un tenant específico. El tenant se especifica al arrancar el servicio y determina qué reglas, qué proveedores y qué configuración se usan. No hay detección de marca en runtime ni condicionales dispersos por el código.
En la práctica esto significa:
- El mismo microservicio puede autenticar usuarios via VTEX en una marca y via OAuth en otra, sin que la lógica compartida cambie.
- Las particularidades de cada país o marca viven en implementaciones específicas de reglas que se inyectan al arrancar el servicio.
- Agregar soporte para una nueva marca se hace mediante configuración e inyección de lógica, sin modificar código existente.
Para entender en detalle cómo funciona este modelo, ver El modelo multi-tenant.
El estado actual
La plataforma está en un momento de transición activa en dos frentes.
El primero es estructural: hay servicios que crecieron sin un modelo claro y hoy concentran responsabilidades de varios dominios. El trabajo en curso es separar esos dominios de forma incremental, siguiendo el modelo de un microservicio por dominio.
El segundo es de comunicación: el sistema está migrando de un modelo de llamadas síncronas entre microservicios hacia comunicación orientada a eventos. El objetivo es que cada microservicio pueda desplegarse y operar de forma independiente, sin depender del estado o disponibilidad de los demás.
Ambas transiciones son conocidas, están documentadas y avanzan de forma incremental. Esta documentación existe para que ese proceso sea ordenado: registrar lo que tenemos, definir hacia dónde vamos y documentar las decisiones que tomamos en el camino.
Si acabas de unirte al equipo, continúa con los fundamentos en este orden: