Plataforma SaaS de inteligencia de precios para eCommerce: el caso Revaly

Revaly es una plataforma SaaS que da a una tienda online inteligencia de precios de su competencia. La promesa del producto es también su desafío técnico.

Dejar de competir sólo por precio exige primero saber cuál es el precio del otro, y eso significa leer miles de fichas de producto de sitios ajenos, cada uno con su estructura, y sostener esa lectura en el tiempo sin que se rompa.

Y encima es un producto multi cliente, con todo lo que eso arrastra.

• Catálogos heterogéneos: cada sitio describe su producto a su manera, y una regla fija se rompe con el primer rediseño.
• Aislamiento entre clientes: los datos de una tienda no pueden filtrarse a otra, y eso hay que garantizarlo en la capa de API.
• Consumo por plan: si el producto se vende por volumen de URLs monitoreadas, hay que contarlas y limitarlas de verdad.

Sin resolver las tres a la vez, el producto funciona en la demostración y no en producción.

Desarrollamos la plataforma sobre una arquitectura de tres servicios, con bases separadas para que la gestión de esquema de uno no altere las tablas del otro.

La administración de tenants y cuotas vive en su propio servicio, consultado por HTTP en lugar de compartir tablas.

Tres servicios con responsabilidades separadas

• Servicio de administración en Java con Spring Boot: tenants, planes y control de cuota, con base propia.
• Backend operativo en Python con FastAPI: extracción, procesamiento y lógica del producto.
• Frontend en React sobre Vite, con el panel de control del cliente.

Multi tenant y planes

• Aislamiento por tenant propagado en la capa de API mediante cabecera de identificación.
• Autenticación delegada en un proveedor gestionado.
• Planes diferenciados por volumen de URLs monitoreadas, desde un nivel gratuito sin tarjeta hasta el corporativo, con facturación de suscripciones integrada.

Leer catálogos que no son propios

• Extracción de fichas de producto de sitios de terceros con asistencia de modelos de lenguaje, para interpretar estructuras heterogéneas sobre una capa de scraping propia.
• Conectores con las plataformas de comercio donde el cliente tiene su tienda, incluida la publicación de cambios de precio hacia ella.

Arquitectura y tecnología

• Spring Boot, FastAPI y React sobre Vite, con PostgreSQL y bases separadas por servicio.
• Stack completo levantable en local con contenedores, con las claves de servicios externos deshabilitadas a propósito.

Cómo se integra y se gobierna la IA generativa

• La solución integra servicios de inteligencia artificial generativa: modelos de lenguaje que redactan, conversan, extraen y estructuran dentro del flujo de trabajo, y no un motor de reglas con respuestas preescritas.
• El consumo se mide y se factura en tokens, separando los de entrada, los de salida y los de escritura y lectura de caché, que son partidas con precios distintos y se contabilizan aparte.
• La telemetría atribuye el consumo por agente y por cliente, así que el presupuesto de tokens se acota y se controla por proyecto en lugar de mirarse como una factura única.
• Los límites viven en la ficha, no en el modelo: una ficha declara roles y topes, y a qué proveedor se traduce cada rol es configuración que se cambia sin tocar al agente.
• La arquitectura es multiproveedor: el proveedor queda fijado por agente y por sesión, nunca por pedido, y el reintento automático contra otro proveedor está apagado a propósito. Si el proveedor falla, el agente frena y lo informa en lugar de seguir con otro en silencio.
• El caché de contexto es la palanca de costo principal, porque la relectura del contexto concentra la mayor parte del volumen de tokens de cualquier operación con agentes. Sostener el caché es lo que evita que la misma tarea cueste varias veces más.
• Y la ventana de contexto mínima se declara por agente: un proveedor que no la cubre queda descartado por arquitectura, no por precio.

Conocé más sobre desarrollo de software y inteligencia artificial.

El producto sostiene lectura de catálogos ajenos, aislamiento por cliente y cobro por volumen, que son las tres cosas que lo hacen vendible.

KPIs iniciales

• Catálogos de terceros sin estructura común, imposibles de leer con reglas fijas.
• Requisito de aislamiento entre clientes y de cuota por plan desde el primer día.

Impacto estratégico

• La extracción asistida por modelos de lenguaje sobrevive a un rediseño del sitio ajeno, donde una regla fija se rompería.
• El aislamiento viaja en la capa de API, no en la disciplina de quien escribe la consulta.
• El control de cuota vive en su propio servicio, así que el plan se hace cumplir de verdad.
• El entorno local levanta el stack completo sin tocar datos reales.