Volver a la arquitectura

Buscador

Motor de búsqueda

No es un servicio aparte: es pg_trgm, una extensión de PostgreSQL que permite buscar por similitud de texto (tolera errores de tipeo) directamente sobre las tablas del catálogo, clientes y variantes.

¿Qué es?

pg_trgm descompone el texto en trigramas (grupos de 3 caracteres) e indexa esas piezas con un índice GIN. Así, buscar "tempera" también encuentra "témpera": no hace falta que la palabra coincida exactamente. Es la extensión activada en 01_extensions.sql y usada por el parámetro ?buscar= de la API (ver config.filters.BuscarFilter).

Dónde se usa hoy

Productos: GET /productos?buscar=témpera — busca en nombre y marca.
Variantes: por SKU o código de barras.
Clientes: por nombre o número de documento.
Búsqueda global de la intranet: la barra superior busca en productos, clientes, pedidos y proveedores ya cargados en el navegador (no vuelve a golpear la API en cada tecla).

Lo que NO existe

No hay Elasticsearch, Solr ni ningún motor de búsqueda dedicado. No hace falta uno aparte con el volumen de catálogo actual (decenas de SKU, no miles).
No hay autocompletado del lado servidor, filtros facetados (conteo por categoría/precio) ni sinónimos configurables — ?buscar= es una coincidencia por similitud simple, no un ranking de relevancia.

Limitaciones y restricciones

Escala: pg_trgm funciona bien hasta cientos de miles de filas; con un catálogo mucho más grande, un motor dedicado (Elasticsearch) rendiría mejor — pero es una decisión para si el catálogo crece así de grande, no algo pendiente de esta versión.
Sin relevancia avanzada: no pondera "producto destacado" ni aprende de clics anteriores.

Propósito del componente

Que buscar "lapiz" encuentre "lápiz", sin necesitar infraestructura adicional, aprovechando algo que Postgres ya sabe hacer bien a esta escala.

Stack

PostgreSQL — pg_trgm Índices GIN django-filter (SearchFilter)

Por qué: evita montar y mantener un servicio de búsqueda aparte (indexación, sincronización, otro punto de fallo) cuando la base de datos ya resuelve el caso de uso real.

Si el catálogo creciera a miles de productos y la búsqueda se quedara corta, Elasticsearch sería la alternativa a evaluar — pero eso es una decisión futura, no parte de lo construido hoy.