WheyScore Backend Node

Problème

Surveiller les prix, générer des rapports et déclencher des notifications exige des routines fiables en arrière-plan — sans dépendre d'une intervention manuelle quand un job échoue ou qu'un marketplace change de mise en page.

Solution et impact

Backend Node.js avec MySQL, node-cron pour les routines de suivi et de rapports, Winston pour des logs structurés et des webhooks pour les alertes d'échec. Docker pour un déploiement reproductible. Le résultat est une automatisation orientée produit avec une observabilité pragmatique, sans APM enterprise.

Architecture et compromis

Trade-off : node-cron dans le process plutôt qu'une file externe (BullMQ/Redis) — suffisant pour le volume actuel, au prix de retries et d'un isolement limités. Séparation claire entre les jobs de collecte, la persistance en MySQL et la couche de notification via webhooks. Winston centralise les logs pour le troubleshooting post-déploiement.

Exploitation et observabilité

Healthchecks HTTP, logs Winston structurés et webhooks pour les échecs de job. Pas de dashboard APM — les alertes et les logs sont la première ligne de défense. Rollback via redéploiement du conteneur Docker.

Défis techniques

Garantir que les jobs planifiés ne dupliquent pas le travail après un restart, maintenir des webhooks fiables quand les API externes échouent, et équilibrer la simplicité opérationnelle avec le besoin futur de métriques par job.

Ce que je ferais autrement

Avec un volume plus important, je migrerais les jobs critiques vers une file avec retries explicites. Aujourd'hui, le design cron + webhooks est adapté ; j'ajouterais des compteurs d'échec par job dans les logs pour réduire le temps de diagnostic.

Décisions documentées (ADR)

• ADR 003 : node-cron vs file externe

  Cron suffisant pour le volume actuel ; une file externe ajouterait de l'infra sans gain proportionnel.

Stack

• Node.js
• MySQL
• node-cron
• Winston
• Webhooks
• Docker