Retour Enterprise
    Haute disponibilité · Durabilité des données

    Vos agents continuent quand un serveur s'arrête.

    StreamFlow exécute vos pipelines sur un cluster multi-nœuds avec un stockage répliqué par quorum. Un nœud peut être tué en pleine écriture, aucun événement acquitté n'est perdu — le failover se mesure en secondes, pas en fenêtres de maintenance.

    N-1 pannes de nœuds toléréesRPO = 0 (prouvé sous chaos)Rolling upgrades sans fenêtreActivation en un clic
    Cluster live · 3 nœuds · replication factor 3
    state:HEALTHY· epoch:1
    node-1Leader
    en service · in-sync
    node-2Follower
    en service · in-sync
    node-3Follower
    en service · in-sync

    Un aperçu du comportement réel : à la perte du leader, un follower est promu (l'epoch avance d'un cran), et chaque événement déjà acquitté avec quorum reste lisible. Le moteur applique cette garantie en CI — voir Preuves.

    Le piège du nœud unique

    Un processus qui crashe ne devrait pas vous coûter les données — ni le SLA. La plupart des plateformes d'agents brillent sur un laptop et s'effondrent dès que la production réclame de la disponibilité, du scale horizontal ou une piste d'audit. Les équipes rafistolent alors reverse-proxies, scripts de failover, réplicas Postgres et bus pub/sub — rien n'ayant été conçu ensemble. Six mois plus tard, le scotch est devenu le produit.

    Sans HA
    Un point unique de défaillance

    Le nœud meurt → les événements en vol s'évaporent, le SLA saute, et la reprise est une chasse manuelle dans les logs. Le scale est plafonné à une machine.

    Avec StreamFlow HA
    Un cluster qui absorbe la panne

    Stockage répliqué à quorum + failover automatique. Les mêmes pipelines qu'au jour 1 tournent partitionnés, répliqués et persistants — sans réécriture.

    Durabilité à quorum

    Acquitté = engagé sur une majorité — ou pas acquitté du tout. Les écritures se répliquent dans le cluster et ne sont ack que lorsqu'une majorité (quorum) a commit. Tuez un nœud en pleine écriture : chaque record acquitté est toujours là. C'est la garantie du plan de données, vérifiée par des tests de chaos qui SIGKILL un broker sous charge.

    Point de reprise
    0 événement perdu

    RPO = 0 pour les écritures acquittées à quorum, en cas de kill dur (acks=all).

    Tolérance de panne
    N-1 nœuds

    Un cluster de 3 nœuds continue de servir malgré la perte d'un nœud ; augmentez le facteur pour plus.

    Reprise d'état fenêtré
    < 5 s RTO

    Crash en pleine fenêtre → reprise depuis le checkpoint → on repart. 0 doublon, 0 perte.

    Honnête sur les deux modes. Le failover non-transactionnel est RPO = 0 (aucune donnée acquittée perdue) avec livraison at-least-once, dédupliquée par un tampon de séquence par producteur. L'exactement-une-fois de bout en bout (transactionnel) est un chemin distinct, opt-in. On dit lequel est lequel — jamais « zéro perte » là où on veut dire « pas de doublons ».

    Deux plans, tous deux tolérants aux pannes

    Le plan de contrôle coordonne. Le plan de données réplique. Ils basculent indépendamment : un hoquet du plan de contrôle ne touche jamais aux événements commités, et une perte de nœud data-plane n'égare jamais le cluster sur l'identité du leader.

    Plan de contrôle · coordination
    Leadership
    Advisory lock Postgres, actif / standby — arbitrage externe, sans ZooKeeper additionnel.
    Anti split-brain
    Chaque promotion incrémente une epoch monotone ; le plan de données rejette toute écriture portant une epoch obsolète.
    Temps de promotion
    ≈ 10 s (heartbeat × 2), plafond SLO à 15 s.
    Plan de données · stockage
    Réplication
    Raft sur gRPC, commit à majorité, facteur de réplication ≥ 1.
    Partitionnement
    Routage par slot sur la clé d'événement — même clé, même propriétaire — scale horizontal, état local.
    Durabilité
    WAL append-only sur un chemin rapide io_uring / Panama ; replay = recovery.

    Du laptop au cluster

    Un clic pour monter l'échelle production. Chaque étape est réversible. HA et event mesh forment une progression cohérente, pas deux produits à évaluer. Chaque niveau préserve vos agents, pipelines, plannings, révisions et audit.

    L1
    Nœud unique
    H2 · log embarqué

    Zéro setup. Idéal pour le dev, les démos, et vos premiers pipelines.

    L2
    Cluster HA
    Postgres · cluster bridge

    Actif/standby avec failover via advisory-lock et une config load-balancer prête à coller. Uptime production.

    L3
    HA + event mesh
    Postgres · StreamFlow mesh

    Stockage répliqué Raft, partitionné entre nœuds. Production à l'échelle, durable N-1.

    L'assistant d'activation — 5 étapes, chacune retryable, chacune réversible

    1. Step 1
      License

      Vérifie que votre plan supporte HA — pas de surprise à l'exécution.

    2. Step 2
      Joignabilité peers

      Sonde chaque nœud configuré ; les problèmes réseau surgissent avant la bascule, pas pendant.

    3. Step 3
      Advisory lock

      Acquiert le lock cluster Postgres qui empêche le split-brain.

    4. Step 4
      Load balancer

      Génère une config nginx / HAProxy / Traefik prête à coller.

    5. Step 5
      Migration data

      H2 → Postgres en un clic, avec rollback — pas de SQL manuel, pas de downtime.

    Restart-safe. L'état de l'assistant vit en base, pas en mémoire. Si le cluster redémarre en pleine migration, il reprend exactement à l'étape en cours — vous ne perdez pas une demi-journée sur un bug de reboot. Chaque action est audit-loggée et gated par RBAC (HA_ACTIVATE · HA_MIGRATE · HA_ROLLBACK).

    Upgrades & reprise après sinistre

    Upgrader sans fenêtre. Récupérer depuis un checkpoint, pas depuis une bande de sauvegarde.

    Upgrades sans downtime
    Nœud par nœud

    Drain d'un nœud, upgrade, réintégration — le reste continue de servir. Pas de fenêtre, pas de « stop the world ». La garde d'epoch empêche un nœud qui revient d'agir sur un leadership obsolète.

    Migration backend en ligne
    Les deux backends en parallèle

    Le Data-Plane switch bascule à chaud : les deux backends tournent pendant la fenêtre, seul le swap du pointeur de lecture actif est atomique. Latence < 5 ms, aucune perte en test. Rollback identique.

    Failover d'agent
    Reprise depuis checkpoint

    Un standby reprend un agent tombé et repart de son dernier checkpoint — pas de zéro. Un watchdog relance automatiquement les agents crashés.

    Producer exactly-once stamping
    Les replays sont court-circuités

    Chaque événement porte une séquence monotone par producteur. Après un kill de leader, l'état producer se reconstruit et les replays doublons sont droppés — dédup sans second système.

    Comment on le prouve

    Chaque garantie de durabilité ci-dessus est un test qui tourne en CI. Pas un slide. Ce sont les tests d'intégration nommés qui font échouer le build si la garantie régresse — la même discipline que pour nos benchmarks publiés.

    Perte de nœud brutale sous charge → zéro donnée acquittée perdue
    streamflow-core · FailoverUnderLoadReplicationTestlost = acked − committed = 0
    SIGKILL d'un broker en pleine production — chaque record acquitté reste lisible
    stress-tests · DurabilityProbe · chaos-broker-killVERDICT PASS · RPO=0
    Crash en fenêtre, reprise depuis checkpoint, propre
    streaming · StreamingCheckpointRecoveryITduplicates 0 · losses 0 · RTO<5s
    Le failover coordonné promeut un standby, epoch +1
    cluster-bridge · E2ECoordinatedFailoverITepoch +1 · real Postgres
    Failover primary/standby d'agent, reprise depuis checkpoint
    agent-runtime · AgentInstanceFailoverTestcheckpoint resume
    L'état producer se reconstruit après kill leader, doublons droppés
    bridge · IdempotentFailoverDedupTestdedup verified

    La promotion de failover est de ~10–15 s (pilotée par heartbeat), pas instantanée — on cite la valeur mesurée, pas celle du marketing. Le geo / multi-région est coordonné par des horloges vectorielles pour l'ordering cross-région ; demandez-nous où en est le staging multi-AZ.

    Enterprise

    Uptime production sans équipe DevOps.

    Un seul binaire : l'écosystème de connecteurs, la compute streaming, le runtime d'agents et le backend de stockage — un seul audit log, un seul vault d'identifiants, un seul assistant HA. Pas d'orchestrateur externe à assembler.

    StreamFlow · Pulse — haute disponibilité & event mesh·N-1 durable · RPO = 0 · activation réversible