> ## Documentation Index > Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Garanties de livraison > Comprendre les garanties de livraison de LaserStream, y compris la livraison en une seule fois, l'ordre des messages, le comportement des notifications de slot et la gestion des forks. LaserStream fournit exactement les mêmes garanties de livraison que les nœuds Geyser. Ce guide couvre ce à quoi vous pouvez vous attendre du comportement de livraison des messages de vos flux LaserStream. Ces garanties s'appliquent aux **abonnements standard** (transactions, comptes, slots, blocs). Les [transactions prétraitées](/docs/fr/preprocessed-transactions/overview) (faisant partie de la livraison de Shred) fonctionnent sous des garanties de livraison distinctes et au mieux. ## Livraison en une seule fois LaserStream garantit une **livraison en une seule fois**. Chaque message est livré à votre flux exactement une fois — vous ne recevrez jamais de messages en double et aucun message ne sera ignoré. LaserStream y parvient en se connectant à plusieurs nœuds Solana simultanément et en dédupliquant les données entrantes avant de les transférer à votre flux. Cette architecture multi-nœuds élimine également les points de défaillance uniques, assurant un temps de disponibilité maximal sans compromettre la précision de la livraison. ## Ordre des messages par niveau d'engagement L'ordre de livraison dépend du niveau d'engagement des messages : ### Confirmé et finalisé Tous les messages **confirmés** et **finalisés** sont livrés dans l'ordre. Vous pouvez compter sur ces niveaux d'engagement pour fournir une vue cohérente et séquentielle de l'état on-chain. ### Traité Tous les messages **traités** sont émis dans l'ordre des slots croissant sauf en cas de fork. En cas de fork, l'ordre des slots peut temporairement dévier à mesure que le réseau se réorganise autour de la chaîne canonique. Une fois le fork résolu, l'ordre croissant reprend. Au niveau d'engagement traité, il y a une petite chance qu'un slot traité soit ultérieurement ignoré ou bifurqué. Geyser n'envoie **pas** de notifications de retour explicites pour les mises à jour bifurquées. Si votre application consomme des données de niveau traité, vous devez tenir compte de la possibilité que certaines mises à jour appartiennent à des slots qui sont finalement abandonnés. Pour les applications nécessitant de la certitude, utilisez le niveau d'engagement **confirmé** ou **finalisé**. ## Ordonnancement au sein d'un slot Au sein d'un seul slot, LaserStream livre les mises à jour de compte et les transactions avec les garanties suivantes : ### Mises à jour de compte avant les transactions Pour chaque transaction, les mises à jour de compte qu'elle a causées sont livrées **avant** la transaction elle-même : ``` → → → ``` ### Ordre inter-transaction LaserStream conserve le même ordre que le [plugin Geyser d'Agave](https://docs.solanalabs.com/validator/geyser#ordering-guarantees). Que les mises à jour de différentes transactions arrivent dans un ordre déterministe dépend de leurs **verrous d'écriture** : * **Même verrou d'écriture** (par ex., trois transactions sur la même pool Raydium) : toujours déterministe. Agave les exécute séquentiellement puisqu'elles écrivent sur le même compte. * **Verrous d'écriture différents** (par ex., deux transactions non liées) : pas nécessairement déterministe. Agave peut les exécuter en parallèle, et leurs mises à jour peuvent être mélangées dans le flux. Pour reconstruire un ordre entièrement déterministe quelle que soit la nature des verrous d'écriture, utilisez l'**index de bloc/transaction** à partir des données de la transaction. ### Normalisation de la version d'écriture LaserStream normalise les versions d'écriture dans son architecture multi-nœuds. Contrairement à Geyser brut ou Yellowstone — où les versions d'écriture sont locales à chaque nœud et peuvent différer — LaserStream fournit des versions d'écriture cohérentes auxquelles vous pouvez vous fier pour ordonner les mises à jour de compte au niveau traité. **Exception temporaire :** Les comptes de plus de 512KB sont actuellement mis en mémoire dans le plugin Geyser pour des raisons de performance, ce qui peut affecter l'ordre déterministe pour ces comptes. Cette limitation sera bientôt supprimée. ## Notifications de slot Les **notifications de slot traitées** arrivent après que tous les messages pour ce slot ont été livrés. Cela signifie que lorsque vous recevez une notification de slot traité, vous pouvez être sûr que toutes les données de mise à jour de transaction et de compte associées à ce slot ont déjà été envoyées à votre flux. Vous pouvez utiliser les notifications de slot comme un signal pour vider ou libérer les données mises en mémoire pour ce slot. ## Continuité des données en cas de déconnexion LaserStream maintient un tampon des données récentes de slot, permettant la [relecture historique](/docs/fr/laserstream/historical-replay) pour jusqu'à **24 heures** (\~216,000 slots) de données passées. Si votre application se déconnecte, vous pouvez vous reconnecter et reprendre à partir de votre dernier slot traité sans manquer de données. Lors de l'utilisation d'un [client SDK LaserStream](/docs/fr/laserstream/clients), cette récupération est gérée automatiquement — le client suit votre position de streaming par numéro de slot et se reconnecte sans interruption. Aucune logique de reconnexion manuelle n'est requise. ## Référence de niveau d'engagement | Niveau | Description | Latence | Ordre | Risque de retour | | ------------ | ------------------------------------------------------------------------------------------------------- | ----------------- | --------------------------------------------------------- | ------------------------------------------------------- | | **Traité** | Inclus dans le bloc le plus récent que le nœud connaît ; pas encore de votes à l'échelle du cluster | \~400ms | Ordre des slots croissant (peut se casser lors des forks) | Petite chance que les slots soient ignorés ou bifurqués | | **Confirmé** | Supermajorité des enjeux (≥66%) a voté sur le bloc (confirmation optimiste) | Quelques secondes | Strictement ordonné | Négligeable | | **Finalisé** | Confirmé et au moins 31 blocs confirmés supplémentaires construits au-dessus (verrouillage de 32 votes) | \~12-15 secondes | Strictement ordonné | Pratiquement irréversible |