Un distribuidor de ferretería o repuestos de autos rara vez tiene menos de 20.000 SKUs activos. Si además suma piezas de recambio históricas, fácilmente supera los 100.000. Si un cliente escribe "Rulemán NSK 6204", espera el resultado antes de terminar de tipear. Si la web se queda pensando 4 segundos, perdiste la venta.
El colapso de la base de datos relacional
En WooCommerce o plataformas monolíticas básicas, cuando el usuario busca, el sistema ejecuta un SELECT * FROM wp_posts WHERE post_title LIKE "%Ruleman%". Esto es un "Full Table Scan". La base de datos tiene que leer fila por fila cada uno de los 100.000 productos.
Si a eso le sumás filtros (Facetas): "... y que la marca sea NSK, y que haya stock en el depósito Norte, y que el precio (que depende de la lista del cliente logueado) esté entre $5.000 y $10.000". El servidor colapsa por CPU o por memoria RAM. Es matemático.
La arquitectura de lectura segregada (CQRS)
Las plataformas Enterprise B2B y SaaS nativos como CommerceUp separan la base de datos de "escritura" de la base de datos de "lectura".
1. Elasticsearch para Búsqueda y Filtros
El catálogo se "aplana" en un documento JSON y se envía a Elasticsearch. Cuando el usuario teclea, se consulta a este motor especializado que soporta:
- Tolerancia a errores (Typo tolerance): Si escribe "Ruleman NCS" (en lugar de NSK), el motor igual lo encuentra.
- Búsqueda por prefijo / SKU parcial: Esencial en B2B donde los clientes buscan partes de un código numérico (ej: "6204").
- Agregaciones ultrarrápidas: Para calcular cuántos productos hay en cada categoría y dibujar el panel de filtros sin esfuerzo.
2. Redis para Pricing e Inventario
El buscador encuentra los IDs de los productos (ej: ID 582). Inmediatamente, la plataforma va a Redis (memoria RAM) para preguntar: "¿Cuál es el precio de la Lista 4 para el ID 582? ¿Y el stock del Depósito A?".
Esta doble lectura (Elasticsearch -> Redis) no toca la base de datos SQL en absoluto. El resultado en pantalla ocurre en ~45 milisegundos.
Sincronización del índice
El desafío técnico no es la lectura, sino mantener Elasticsearch actualizado cuando el ERP cambia algo. Se usan "Workers" asíncronos que escuchan eventos (ej: `ProductUpdated`) y re-indexan ese único documento en background, sin afectar a los usuarios navegando.
