Événements temps réel durables

Scrydon enregistre les événements opérationnels de l'organisation dans un journal durable, limité à l'organisation, avant qu'ils n'atteignent les clients temps réel. Une modification du domaine et son événement sortant sont validés ensemble dans la base de données d'écriture. Un relais publie l'événement validé, et la plateforme stocke un registre ordonné avec un point de contrôle indépendant pour chaque consommateur pris en charge.

Cela fournit une livraison au moins une fois (at-least-once) : un consommateur peut revoir le même événement après une nouvelle tentative, mais il ne perd jamais silencieusement un événement validé. Les consommateurs Scrydon utilisent l'ID de l'événement pour l'idempotence et n'acquittent leur progression qu'une fois le travail à destination réussi.

Les événements temps réel de l'organisation sont de simples signaux d'invalidation. Ils indiquent à un client que des données gouvernées ont changé ; ils ne contiennent pas de copie de remplacement de l'enregistrement gouverné. Le client relit les données via le chemin normal d'autorisation et de politique de données.

Reconnexions du navigateur

Le client org-events négocie le protocole durable avec le serveur temps réel. Les nouveaux serveurs renvoient une clé de curseur opaque, limitée à l'utilisateur connecté et à l'organisation active. Le client enregistre le dernier offset distribué, demande les signaux manqués après la reconnexion, ordonne les enveloppes en direct et de rattrapage, supprime les doublons et fait avancer le curseur après l'exécution du gestionnaire de l'application.

Si l'historique conservé ne couvre plus le curseur enregistré, le client l'efface, appelle le callback de resynchronisation complète gouvernée de l'application et reprend à partir de la dernière position conservée. Pendant un déploiement à versions mixtes, un délai de négociation borné attache les écouteurs de socket hérités, en direct uniquement ; une réponse de capacité durable réussie supprime ce repli.

Les applications qui utilisent subscribeOrgEvents reçoivent les mêmes gestionnaires par nom d'événement qu'auparavant. Les enveloppes durables et le stockage du curseur sont gérés par le noyau partagé du SDK ; le code applicatif doit continuer à traiter chaque signal comme une raison de rafraîchir les données gouvernées.