Épuisé en ligne, encore vendu en boutique.
Une synchronisation nocturne, ce sont des canaux en désaccord pendant des heures. Un flux, c'est chaque canal qui voit le même compteur quelques instants après la vente.
Règles et marges, appliquées en vol
Ingérez les flux concurrents, signaux de demande et niveaux de stock en streams. Des stages de règles encodent vos planchers, marges et contraintes de marque de façon déterministe ; un stage LLM peut ne revoir que les mouvements sensibles. Nouveau prix publié comme événement — au web, à l'app, à la marketplace et au shelf-edge en même temps.
Un seul compteur live par SKU, sur chaque canal
L'état par clé par SKU maintient une position live, mise à jour par chaque commande, retour et mouvement de stock au moment où il se produit. Un join flux-flux corrèle une commande avec son fulfilment ; les seuils déclenchent réappro et stop-sell avant la survente, pas après.
Décidez sur la session, pendant la session
Fenêtrez le clickstream live par visiteur — vues, paniers, hésitations — et confiez le contexte enrichi à un stage de règles pour l'évident (panier abandonné, back-in-stock) et à un LLM pour les cas de jugement. La réponse atteint le shopper tant que l'onglet est encore ouvert.
Les canaux s'abonnent — ils ne se synchronisent pas
Web, app, systèmes en magasin, marketplaces : chacun est un abonné aux mêmes topics, pas une copie qui attend le batch de la nuit. Les plateformes e-commerce se branchent via des sources webhook ; ERPs et magasins legacy via JDBC et fichiers ; le reste, via l'API HTTP.
Pourquoi ça tient
Conçu pour la réalité des pics de saison.
Retries ≠ commandes doubles
Dedup par clé et gardes d'idempotence absorbent les retries de webhooks et les réseaux instables — un événement renvoyé ne décrémente pas le stock deux fois.
Vérité event-time
Les fenêtres suivent le moment où les choses se sont produites, les watermarks gèrent les retardataires, et les vrais retards atterrissent en DLQ au lieu de corrompre silencieusement les compteurs.
État récupérable
Offsets par agent et état de fenêtre checkpointé survivent à un redémarrage — votre position de stock ne repart pas de zéro parce qu'un nœud est tombé.
À quoi ça ressemble
Un garde-stock live tient dans un fichier.
Commandes et mouvements de stock fusionnent en une position par clé par SKU ; les seuils agissent avant la survente.
1# pulse.yaml — inventory guard
2source:
3 kind: webhook # orders + stock moves in
4
5stages:
6 - name: position
7 engine: streaming
8 operators:
9 - aggregate:
10 keyBy: sku
11 fields:
12 sold: sumWhere(type == 'order')
13 received: sumWhere(type == 'restock')
14
15 - name: guard
16 engine: rule-based
17 rules:
18 - "received - sold < safety_stock"
19
20 - name: act
21 engine: mcp
22 mcpTools: [ commerce.setAvailability ]
23
24sink:
25 kind: webhook # ops alerting
26 url: ${secret:OPS_WEBHOOK}
27- 1
Scaffold.
pulse new inventory --source webhook --stage streaming:position --stage rule-based:guard --stage mcp:act --sink webhook - 2
Pointez votre plateforme dessus.
Enregistrez l'URL du webhook dans votre plateforme commerce — commandes et événements de stock arrivent à mesure qu'ils se produisent.
- 3
Déployez & observez.
pulse deploy . && pulse events tail --topic inventory.guard.outChaque décision de stock bas, en direct.
- 4
Laissez les canaux s'abonner.
Web, app et systèmes magasin lisent les mêmes topics via l'API ou SSE — fini la synchro de nuit.
Vendez la dernière unité une seule fois.
Voyez commandes et stock fusionner en une position live en quelques minutes — sans installation, sans inscription. Puis auto-hébergez-le à côté de votre stack.
Pulse est gratuit et auto-hébergé. HA multi-nœuds, géo-réplication et gouvernance sont inclus dans StreamFlow Enterprise.