¿Mi lógica para caché distribuido está sobreingeniería?

Blues

Estoy diseñando un microservicio que consulta datos de productos (stock, precios) desde una API externa lenta (~2s por request). Para optimizar, implementé un sistema de caché distribuida con Redis, pero mi arquitectura actual incluye: 1) un worker que precarga el caché cada 5 minutos, 2) un fallback a la API si el caché falla, y 3) un mecanismo de invalidación por webhook. ¿Creen que esto es demasiado para un equipo pequeño? ¿Alguien ha usado algo más simple como node-cache compartido? La lógica de invalidación me está volviendo loco.

Urban

Depende del volumen de datos y la tolerancia a datos obsoletos. Si la API tarda 2s, un TTL largo (ej: 10 min) sin invalidación puede ser suficiente. El webhook suena a sobreingeniería si la fuente externa no notifica cambios frecuentemente. ¿Has medido cuántas veces se actualizan los productos? Si es diario, un worker simple con TTL basta.

Sculpture

Coincido, pero añadiría que el fallback a API es buena práctica. Sin embargo, el precarga cada 5 minutos puede generar picos. ¿Por qué no usar lazy loading con TTL? Y para invalidación, un patrón cache-aside simple. Redis con EXPIRE por producto. El webhook solo si la API soporta eventos push.

Blues

Gracias por los comentarios. La API se actualiza cada hora aprox, pero no tenemos control sobre cuándo. El webhook lo monté porque el equipo de datos dijo que podían avisar, pero aún no lo implementan. Quizás me estoy adelantando. ¿Recomiendan quitar el worker y solo usar TTL + lazy loading? Me preocupa el primer request a un producto nuevo, que tardaría 2s.

Retro

Podrías pre-cargar solo los productos más populares con un script nocturno, no cada 5 minutos. Para el primer request lento, usa un stale-while-revalidate en caché: devuelves dato viejo mientras actualizas en background. Redis no lo soporta nativo, pero puedes emularlo con dos keys: una con TTL corto y otra backup.

PC

Opinión impopular: Si el equipo es pequeño, considera no usar Redis aún. node-cache con clustering y un sticky session puede funcionar para ~1000 productos. Luego migras. La complejidad de Redis (monitoreo, persistencia) puede ser un costo oculto. Yo lo haría simple primero.

Blues

Buena idea lo de 'stale-while-revalidate'. No lo había considerado. Y sobre lo de node-cache, lo probaré en un entorno de staging. Creo que me dejé llevar por la emoción de usar Redis. Reduciré la complejidad: worker nocturno, TTL de 10 min, y quito el webhook hasta que sea necesario. ¡Gracias a todos!

Developer

Si el equipo es pequeño, node-cache con sticky session funciona, pero ojo: si escalas horizontalmente sin sesiones pegajosas, cada nodo tendrá su propia copia, y el primer request a un nodo nuevo será lento. Una alternativa ligera es usar lru-cache con un tamaño máximo y TTL, y para la recarga nocturna, un simple setInterval en un worker dedicado. Redis no es sobreingeniería si ya tienes experiencia, pero para 1000 productos, una base de datos en memoria del proceso basta. El webhook lo descartaría totalmente a menos que tengas un SLA de segundos.

Crime

Exacto, el sticky session es el talón de Aquiles si escalas. Pero con 1000 productos y un equipo pequeño, dudo que necesiten escalar horizontalmente de inmediato. Si lo hacen, mejor usar un caché compartido como Redis desde el principio. Otra opción: keyv con adaptador SQLite, que da persistencia sin la complejidad de Redis. ¿Alguien ha probado eso en producción?

Blues

Keyv con SQLite es interesante para persistencia local, pero cuidado: SQLite no está diseñado para alta concurrencia de escritura. Si varios workers escriben, tendrás lock contention. Para 1000 productos con TTL de 10 min y recarga nocturna, node-cache con lru-cache es más que suficiente. El overhead de Redis o SQLite no se justifica. Si escaláis a futuro, entonces sí, Redis. Pero hoy, KISS.