El Problema del Que Nadie Habla Hasta Que Es Demasiado Tarde

Me llaman para reparar portales B2B que ya están rotos bajo carga. Los síntomas son siempre los mismos: flujos de compra que se interrumpen en horas pico, reglas de precios que devuelven resultados inconsistentes para el mismo cliente, inventarios que se dessincronizan y un equipo de operaciones que parchea datos manualmente cada mañana antes de que abra el turno de ventas.

Nada de esto son fallas aleatorias. Son decisiones arquitectónicas que tenían sentido al lanzamiento y se convirtieron en pasivos al escalar. Construir un portal B2B no es el mismo problema que construir un sitio de e-commerce para consumidores, y tratarlo como tal es donde la mayoría de los proyectos fallan.

Por Qué los Portales B2B Son una Bestia Diferente

Los sitios para consumidores venden un precio a un comprador. Los portales B2B tienen que gestionar niveles de precios específicos por cliente, tramos de descuento por volumen, anulaciones contractuales, códigos promocionales superpuestos sobre tarifas negociadas y, a veces, reglas de moneda o impuestos que varían por entidad compradora. Una sola acción de "agregar al carrito" puede necesitar resolver seis o siete reglas de precio en secuencia antes de poder mostrar un número.

Súmele a eso: órdenes de compra, términos de crédito, flujos de aprobación, jerarquías de cuentas (una empresa madre con cinco subsidiarias cada una con su propio acceso al catálogo) e integración con un ERP o sistema de inventario que no fue diseñado con tráfico web en tiempo real en mente.

Este es el entorno para el que diseño. Las decisiones que se toman a nivel de arquitectura — antes de que se escriba una sola línea de código de aplicación — determinan si ese portal servirá al 10x del volumen actual o colapsará al 3x.

Principio 1: Separar el Motor de Precios de la Capa de Presentación

Los peores portales que he visto incorporan la lógica de precios directamente en el pipeline de renderizado del front-end. Cada carga de página recalcula precios desde cero, golpeando la base de datos en cada solicitud. A bajo volumen es invisible. A escala es un punto único de falla que derriba todo el sitio.

Siempre diseño un servicio de precios dedicado — un componente separado e independientemente desplegable responsable de una sola cosa: resolver el precio correcto para una combinación dada de producto, cliente y cantidad. Este servicio mantiene su propia caché de reglas de precios, se actualiza de forma asíncrona cuando cambian las reglas y expone una API interna limpia que el resto de la aplicación llama.

El resultado: la resolución de precios se vuelve rápida y predecible independientemente de los picos de tráfico, y los cambios en la lógica de precios pueden desplegarse sin tocar el storefront.

Principio 2: Diseñar la Base de Datos para Lecturas, No Solo para Escrituras

La mayoría de los portales B2B leen datos mucho más de lo que los escriben. Un comprador navega un catálogo durante veinte minutos y luego coloca un pedido. Sin embargo, la mayoría de los esquemas que heredé están optimizados para escrituras transaccionales — normalizados al tercer grado — lo que obliga a las consultas de lectura a unir ocho tablas para mostrar una sola tarjeta de producto.

La solución no es desnormalizar todo. La solución es introducir modelos de lectura: estructuras de datos construidas específicamente para reflejar cómo se mostrarán los datos, no cómo se almacenan. Pueden ser vistas materializadas en la base de datos, una réplica de lectura secundaria o un índice de búsqueda ligero como Elasticsearch para consultas de catálogo.

Para pymes en crecimiento, típicamente recomiendo comenzar con una réplica de lectura y una capa de caché simple (Redis funciona bien aquí). Solo esto puede reducir los tiempos de carga de páginas de catálogo entre un 60 y un 80 por ciento sin cambiar el esquema central.

Si ya está viendo este tipo de síntomas, mi artículo sobre cuellos de botella en bases de datos en pymes en crecimiento profundiza en el lado del diagnóstico.

Principio 3: Tratar la Integración con ERP e Inventario como Asíncrona por Defecto

Las integraciones más frágiles que he visto son las que hacen llamadas síncronas a un ERP durante una solicitud del usuario. El usuario hace clic en "realizar pedido", el portal llama a la API del ERP para reservar stock, el ERP está lento ese día y el usuario obtiene un error de tiempo de espera — o peor, una excepción no controlada que corrompe el registro del pedido.

Diseño estas integraciones para que sean orientadas a eventos y asíncronas. El portal registra la intención (el pedido), publica un evento en una cola de mensajes y devuelve una confirmación al usuario de inmediato. Un trabajador en segundo plano recoge ese evento, llama al ERP, reconcilia el inventario y actualiza el estado del pedido. Si el ERP no está disponible temporalmente, el evento espera en la cola y reintenta — no falla la transacción del usuario.

Este patrón también hace que la integración sea resiliente ante actualizaciones del ERP, cambios de proveedor y el inevitable anuncio de "vamos a migrar a un nuevo ERP en el tercer trimestre". Se cambia el trabajador, no el portal.

Para una visión más amplia de cómo funcionan estos patrones de integración, vea mi artículo sobre integración de APIs personalizadas.

Principio 4: Cachear Agresivamente, Invalidar con Precisión

El caché es la herramienta de rendimiento con mayor apalancamiento en un portal B2B, y la mayoría de los equipos o no cachean suficiente o cachean demasiado ampliamente. No cachear suficiente significa que cada solicitud golpea la base de datos. Cachear demasiado ampliamente significa que un cliente ve el precio de ayer después de una actualización de contrato.

Mi enfoque: cachear en múltiples capas con reglas de invalidación explícitas. El contenido del producto (descripciones, imágenes, especificaciones) puede cachearse durante horas — cambia raramente. Las reglas de precios se cachean a nivel del servicio de precios y se invalidan solo cuando cambia una regla para ese cliente o grupo de productos específico. Los recuentos de inventario nunca se cachean por más de 30 segundos en SKUs de alta velocidad.

La clave es saber qué datos toleran cierta antigüedad y cuáles no. Mostrar una descripción de producto cacheada está bien. Mostrar un precio cacheado después de una actualización de tarifa negociada es una disputa de facturación esperando suceder.

Principio 5: Planificar las Jerarquías de Cuentas desde el Primer Día

Este es el que más frecuentemente veo omitido. Una startup cierra su primer trato empresarial, y el comprador corporativo dice: "Necesitamos compras separadas para nuestras divisiones de Norteamérica y EMEA, pero facturación consolidada a nivel de la empresa madre."

Si el modelo de datos no soporta jerarquías de cuentas, ese requisito se convierte en una construcción personalizada de seis semanas. Si se diseñó desde el principio, es un cambio de configuración.

Siempre modelo las cuentas con una relación padre-hijo en el esquema, incluso si la primera versión del portal no tiene clientes corporativos. El costo de agregarlo al principio es unas pocas horas. El costo de incorporarlo retroactivamente es un sprint completo y una migración de datos.

Qué Aspecto Tiene Esto en la Práctica

Un portal B2B construido sobre estos principios no se ve dramáticamente diferente para el usuario final. Carga más rápido. Pone precios correctamente. No muestra la página de "algo salió mal" durante el lanzamiento de un producto.

Para el equipo de desarrollo, parece un diseño inicial más complejo. Esa inversión se recupera la primera vez que un cliente importante ejecuta una campaña de pedidos masivos y el sistema la maneja sin intervención.

Si está evaluando si la arquitectura de su portal actual aguantará — o está planificando uno nuevo — contácteme. He construido estos sistemas en manufactura, distribución y servicios profesionales, y me alegra hablar sobre su situación específica.