Poner precio a un catálogo contra una tienda que no controlas

Si revendes, tus precios son una función de los precios de otro. Suena a problema de integración. En realidad es un problema de caché, y equivocarse ahí es como una tienda acaba mintiendo sobre sus precios o cayéndose cuando la tienda de origen tiene una mala tarde.

Por qué fallan los dos enfoques obvios

Consultar al cargar la página. Una página de catálogo con treinta productos se convierte en treinta llamadas HTTP salientes. La carga queda limitada por la más lenta, así que cuando el origen va lento tu tienda va lenta, y cuando está caído tu tienda está caída. Has cogido una dependencia que no puedes arreglar y la has puesto delante de cada visita.

Exportar cada noche. Sin riesgo de latencia, pero la tienda se equivoca durante hasta veinticuatro horas. Las rebajas del origen empiezan y terminan sin avisar, y quien llegue después de que acabe una paga un precio que ya no puedes sostener. O te comes la diferencia en miles de pedidos.

Ninguno es un problema de ajuste fino. Los dos están mal de raíz: uno acopla la disponibilidad, el otro acopla la frescura.

Caché de vida corta

El camino intermedio es poco llamativo y correcto: consultar de forma programada, guardar el resultado y servir desde el almacén. En WordPress eso es un transient con caducidad.

Lo que lo hace funcionar es que la página nunca dispara una consulta. El renderizado lee la caché y solo la caché. Si falta el valor, la página muestra el último precio conocido o esconde el producto; no va a preguntar. La actualización ocurre en cron, fuera de banda, donde una respuesta lenta del origen no le cuesta nada a nadie.

La frescura pasa a ser un dial en lugar de una propiedad de la arquitectura. A un catálogo que cambia a diario le basta una actualización diaria; uno que se mueve cada hora hay que releerlo cada hora. Estás eligiendo cuánto estás dispuesto a equivocarte, que es la forma honesta de esta decisión.

Pregunta por todas las regiones y luego decide

Aquí viene la parte propia de la reventa. El mismo producto suele tener un precio distinto en cada tienda regional, así que «el precio del origen» no es un número. Es un conjunto.

Colapsar ese conjunto en un número es una decisión de negocio, no técnica, y cambia. Tomar el precio regional legítimo más bajo. Tomar una región fija por normativa fiscal. Tomar la mediana más un margen. Cualquiera puede ser correcto, y cuál lo es depende del mercado y de la ley.

Así que ponlo tras una interfaz:

interface IProductPriceStrategy
{
    public function choose(array $pricesByCurrency): Price;
}

final class ChooseLowestPriceStrategy implements IProductPriceStrategy { /* … */ }

La estrategia es el único sitio que conoce la regla. Cambiarla es una clase, no una cacería por el código en busca de cada lugar donde se calculó un precio. Esto importa más de lo que parece: las reglas de precio son justo el tipo de lógica que acaba copiada en una plantilla, un endpoint REST y un script de exportación, y luego diverge.

Tipa las respuestas del origen

Parsea a DTOs tipados en vez de leer claves de array sobre la marcha:

$prices = GetPricesResponse::fromArray($body);   // lanza si el formato cambió

Si no, una API que renombra un campo te dará null, que se convierte en 0, que se convierte en un producto a precio cero en una tienda en producción. El fallo que quieres es una excepción ruidosa durante la actualización programada, donde no la mira nadie salvo el log. El fallo que obtienes sin DTOs es silencioso y lo descubre un cliente.

Lo que cuesta

La caché es una segunda fuente de verdad, y las segundas fuentes de verdad se desincronizan. Un producto retirado en el origen sigue en tu catálogo hasta que la siguiente actualización lo note. Eso hay que tratarlo de forma explícita: o la actualización reconcilia las bajas, o los productos llevan una marca de «visto por última vez» y los rancios se ocultan.

También hay un problema de arranque en frío. Una caché vacía tras un despliegue significa que ningún producto tiene precio hasta que termine la primera actualización. Calentarla como parte del despliegue es fácil de olvidar y muy visible en producción.

La regla general

Cuando dependes de un sistema que no controlas, decide por separado cuánta frescura necesitas y cuánta disponibilidad. Consultar en línea acopla ambas al otro sistema. La caché te deja comprar disponibilidad pagando con obsolescencia, y el tipo de cambio de esa operación lo eliges tú.