Un distribuidor promedio tiene 5.000 SKUs y 500 clientes, cada uno con una condición comercial distinta. Esto significa que la plataforma debe resolver 2.5 millones de combinaciones de precios posibles. Hacerlo en menos de 100ms es el mayor desafío de ingeniería del B2B.

El antipatrón: Live API Pricing

El error de los arquitectos junior: "Los precios cambian mucho, así que hagamos que el frontend llame a la API del ERP cada vez que renderiza el catálogo".

Resultado: Un cliente entra a la categoría "Herramientas" (50 productos). El ecommerce hace 50 llamadas (o 1 llamada masiva pesada) al ERP. El ERP tarda 3 segundos en calcular. El cliente abandona el sitio. El ERP se satura.

La solución: Invalidation & Tiered Caching

Los precios no se calculan al vuelo. Se pre-calculan o se calculan una vez y se cachean. En plataformas serias como CommerceUp, la arquitectura de precios funciona así:

1. Indexación plana (Elasticsearch / Redis)

No se usan tablas SQL (JOINs) para mostrar precios en los listados. Cuando el ERP notifica un cambio de precio, el middleware actualiza un índice clave-valor en memoria (Redis). Clave: price:sku_123:customer_456. Valor: 1500.00.

2. Jerarquía de resolución (Fallback)

Cuando el cliente 456 ve el SKU 123, el motor de pricing busca en memoria en este orden exacto (cortocircuitando apenas encuentra match):

  1. ¿Hay un override manual para Cliente 456 + SKU 123? (Sí/No)
  2. ¿Hay un contrato/lista vigente para el grupo "VIP" al que pertenece el cliente? (Sí/No)
  3. ¿Hay un descuento por volumen aplicable para la cantidad del carrito? (Sí/No)
  4. Precio base (Default).

Toda esta cascada ocurre en Redis usando LUA scripts en microsegundos.

Sincronización eventual asíncrona

¿Qué pasa si el precio cambia en el ERP mientras el cliente navega? Usamos un modelo asíncrono. El ERP emite un evento PriceUpdated. Una cola de mensajes (RabbitMQ/Kafka) lo toma, invalida la clave de Redis y la recalcula. El impacto es nulo en el cliente, y el nuevo precio estará disponible en segundos.

Validación pre-checkout

La única llamada síncrona al ERP aceptable en temas de precios es en el botón de "Confirmar Pedido". Ahí se verifica que los precios cacheados coincidan exactamente con la realidad del ERP para evitar discrepancias legales.

Preguntas frecuentes

¿Por qué el ecommerce B2B es lento al cargar precios?
Suele ocurrir cuando la plataforma consulta el precio al ERP en tiempo real para cada producto que el usuario ve en pantalla. Esto no escala y genera cuellos de botella.
¿Qué es una caché de precios jerárquica?
Un sistema que almacena precios en memoria (como Redis) resolviéndolos por orden de prioridad: 1) Precio negociado cliente > 2) Descuento segmento > 3) Precio base. Evita consultar a la base de datos.