EN ← Volver al Portafolio

Toy Sentinel

Plataforma de Inteligencia de Retail Orientada a Eventos

Una plataforma de monitoreo distribuido que rastrea continuamente productos coleccionables en múltiples tiendas de comercio electrónico, detecta cambios de inventario y precios, y entrega alertas en tiempo real a suscriptores vía Telegram.

Rol Fundador y Desarrollador Principal
Estado Activo — Producción
Suscriptores 200+
Node.js MongoDB Redis Telegram API Web Scraping Arquitectura Orientada a Eventos Sistemas Distribuidos

El Problema

Las figuras coleccionables ocupan un nicho de retail particularmente difícil. Los artículos populares se agotan en cuestión de horas tras publicarse. Las bajadas de precio son temporales y sin aviso previo. Los restocks ocurren sin notificación simultáneamente en múltiples tiendas.

Los coleccionistas que quieren mantenerse informados enfrentan un proceso manual tedioso:

  • Revisar múltiples sitios de tiendas repetidamente durante el día.
  • Comparar precios manualmente en Amazon, MercadoLibre y tiendas especializadas.
  • Perder restocks o descuentos porque no existe ningún sistema de notificación.
  • Descubrir productos agotados minutos después de que se publicaron.

El problema no es la disponibilidad de la información — es la velocidad y el esfuerzo necesarios para actuar sobre ella.

La Solución

Toy Sentinel elimina por completo el monitoreo manual. La plataforma rastrea continuamente los listados de productos en múltiples fuentes de retail, detecta cambios significativos — nuevos listados, bajadas de precio, restocks — y publica notificaciones estructuradas en canales de Telegram donde los suscriptores las reciben en tiempo real.

Los coleccionistas ya no necesitan revisar sitios web. La plataforma vigila por ellos y les alerta en el momento en que ocurre algo relevante — antes de que se agote el inventario.

El resultado es un sistema que opera continuamente en producción, atiende a más de 200 suscriptores diariamente y demuestra qué separa a un sistema distribuido funcional de un demo de fin de semana.

Arquitectura del Sistema

La plataforma está construida como un pipeline de componentes desacoplados. El scraping, la detección de cambios y la entrega de notificaciones están intencionalmente separados — cada uno puede fallar, reintentar o escalar de forma independiente.

Tiendas de Retail
Amazon · MercadoLibre · Tiendas Especializadas
Scrapers
Parser de Productos
Normaliza al modelo común
Almacén MongoDB
Estado del producto e historial de precios
Motor de Cambios
Diferencia estado actual vs. anterior
Generación de Eventos
Nuevo listado · Bajada de precio · Restock
Cola Redis
Desacopla scraping de entrega
Consumidor Telegram
Entrega asíncrona con rate limiting
Canales Telegram → Usuarios

Desafíos de Ingeniería

Los Sitios de Retail Cambian con Frecuencia

Cada tienda expone los datos de productos de forma diferente — distintas estructuras HTML, patrones de carga dinámica, medidas anti-scraping y nombres de campos inconsistentes. Los layouts cambian sin aviso y rompen silenciosamente la lógica de extracción.

Solución

Se construyeron estrategias de extracción específicas por tienda, encapsuladas detrás de una interfaz de producto común. Cada scraper normaliza la salida al mismo modelo interno, de modo que los componentes downstream están completamente aislados de los cambios específicos de cada retailer.

Notificaciones Duplicadas y Ruidosas

Sin salvaguardas, las fluctuaciones menores de precio o los raspeos repetidos del mismo listado generan múltiples alertas. Los suscriptores que reciben notificaciones duplicadas pierden rápidamente la confianza en la plataforma y se dan de baja.

Solución

Se implementó lógica de deduplicación de eventos en el Motor de Cambios. Los eventos solo se generan cuando se supera un umbral significativo — no en cada ciclo de scraping — y se les asigna una huella digital para evitar la re-publicación de eventos idénticos.

Límites de Rate de Telegram bajo Carga

Cuando múltiples productos cambian simultáneamente, enviar todas las notificaciones a la vez alcanza los límites de rate de la API de Telegram, causando fallos en la entrega de mensajes y requiriendo lógica compleja de reintentos en todo el sistema.

Solución

Se introdujo una cola de mensajes respaldada por Redis entre la generación de eventos y la entrega. El consumidor de Telegram procesa la cola de forma asíncrona a una velocidad controlada, desacoplando completamente el throughput del cadencio de scraping.

Funcionalidades Clave

🔍
Monitoreo Multi-Fuente
Módulos de scraping independientes para Amazon, MercadoLibre y tiendas especializadas — cada uno normalizado a un modelo de producto compartido.
Detección Orientada a Eventos
Los cambios de precio generan eventos en lugar de notificaciones inmediatas, permitiendo agrupación, filtrado y priorización antes de la entrega.
📉
Historial de Precios
Los productos mantienen un historial completo de precios, permitiendo detección de descuentos, análisis de tendencias y cálculos precisos de ahorro.
📦
Alertas de Restock
Detecta cuando productos previamente agotados vuelven a estar disponibles y encola inmediatamente una notificación.
🚦
Entrega por Cola
La cola Redis desacopla el scraping de la entrega de mensajes, previniendo fallos por límite de rate y habilitando lógica de reintento.
📲
Distribución por Telegram
Alertas estructuradas entregadas en canales de Telegram con imagen del producto, precios, ahorros, info del retailer y enlace directo de compra.

Formato de Notificaciones

Cada alerta está estructurada para darle a los suscriptores todo lo que necesitan para tomar una decisión de compra al instante — sin abrir un navegador.

Canal de Telegram de Toy Sentinel mostrando notificaciones de bajadas de precio en tiempo real

Las notificaciones incluyen imagen del producto, precio actual y anterior, porcentaje de ahorro, retailer, estado de stock y un enlace directo de compra — todo lo necesario para actuar de inmediato.

Métricas de la Plataforma

Toy Sentinel es un sistema de producción en vivo, no un demo. Estas métricas reflejan una escala operativa real.

200+
Suscriptores activos en los canales
24/7
Monitoreo automatizado continuo
Multi
Retailers monitoreados simultáneamente
Tiempo Real
Entrega de alertas al detectar el evento

A diferencia de demos de portafolio que simulan condiciones de producción, Toy Sentinel opera continuamente, atiende a usuarios reales diariamente y ha sobrevivido cambios de estructura en retailers, actualizaciones de la API de Telegram y fallos de infraestructura.

Tecnologías y Arquitectura

Scraping y Extracción
Node.js Scrapers Personalizados Parsing de HTML Adaptadores por Retailer
Procesamiento de Eventos
Motor de Detección de Cambios Deduplicación de Eventos Cola Redis Consumidores Asíncronos
Persistencia
MongoDB Historial de Precios Modelo de Estado de Producto
Distribución
Telegram Bot API Rate Limiting Gestión de Canales
Operaciones
Servicios de Larga Duración Recuperación de Errores Monitoreo

Aprendizajes

1
El desacoplamiento no es una optimización — es un requisito de confiabilidad. Conectar el scraping directamente a la entrega de notificaciones significa que un fallo de la API de Telegram detiene todo el pipeline. La cola Redis no se añadió por escala; se añadió porque el sistema no podía sobrevivir sin ella.
2
Los sitios web no son APIs estables. Cada integración con un retailer se ha roto al menos una vez por un cambio de layout sin anunciar. Tratar los scrapers como frágiles y escribirlos para que fallen visiblemente — en lugar de producir datos corruptos silenciosamente — es el único enfoque sostenible.
3
La calidad de las notificaciones determina la retención de suscriptores. Una notificación duplicada, un falso positivo o un precio ya corregido cuando el usuario hace clic erosiona la confianza de inmediato. La lógica de deduplicación del Motor de Cambios existe para proteger la experiencia del suscriptor, no solo la eficiencia del sistema.
4
Producción es un problema diferente al desarrollo. Operar el sistema 24/7 reveló modos de fallo que ningún test cubre: fugas de memoria en scrapers de larga duración, fallos de red transitorios a mitad de página, expiración de sesión de Telegram y agotamiento del pool de conexiones de MongoDB bajo carga.
5
La arquitectura orientada a eventos escala el valor para el usuario, no solo el throughput. El mayor beneficio del modelo de eventos no fue el rendimiento — fue la capacidad de añadir nuevos tipos de eventos (restocks, nuevos listados) sin modificar las capas de entrega o scraping. La arquitectura hizo el producto más fácil de extender.
6
Los usuarios reales son la mejor herramienta de observabilidad. Con más de 200 suscriptores recibiendo alertas diarias, los usuarios reportan notificaciones rotas más rápido que cualquier panel de monitoreo. El feedback de los suscriptores se convirtió en un sistema de alerta temprana para cambios en retailers y fallos del pipeline.