Aller au contenu

Peering inter-instances

Le peering permet à plusieurs instances Stream Fusion de partager leurs torrents privés de manière sécurisée et chiffrée. L'instance source exporte les torrents de sa base privée (PostgreSQL), et l'instance cible les insère dans sa base publique (Meilisearch) — enrichissant ainsi son catalogue pour tous ses utilisateurs sans compromettre la sécurité des données sources.

Concept

graph LR
 A["Instance A<br/>Cache: torrents FR"] <-->|" HMAC + Fernet"| B["Instance B<br/>Cache: torrents VO"]

 style A fill:#311b92,color:#fff
 style B fill:#1b5e20,color:#fff

Chaque instance peut à la fois exporter son cache (via une PeerKey) et importer le cache des autres (via une PeerInstance).

Modèle de données

PeerKey (authentification entrante)

Une PeerKey autorise une instance distante à interroger votre cache.

Propriété Description
key_id UUID unique identifiant la clé
secret Secret 256-bit hex (affiché une seule fois)
name Nom descriptif
is_active Si la clé est active
rate_limit Max requêtes par fenêtre
rate_window Durée de la fenêtre (s)
expires_at Date d'expiration (optionnelle)

PeerInstance (connexion sortante)

Une PeerInstance configure la connexion vers une instance distante.

Propriété Description
name Nom descriptif
url URL de l'instance distante
key_id UUID de la PeerKey distante
secret_encrypted Secret distant chiffré au repos (Fernet)
is_active Si la connexion est active
sync_enabled Si la sync automatique est activée
sync_cron Horaire de synchronisation

Toutes les PeerInstances sont persistées dans la table PostgreSQL peer_instances. Au démarrage du worker Taskiq, les schedules sont automatiquement ré-enregistrés dans Redis via seed_peer_schedules_from_db() — aucune reconfiguration manuelle nécessaire après un redémarrage.

Flux de données

Sync incrémentale

sequenceDiagram
 participant B as Instance B
 participant A as Instance A

 Note over B,A: 1. Admin B crée une PeerKey sur A
 Note over B,A: 2. Admin B configure une PeerInstance vers A

 loop Sync périodique (cron)
 B->>A: POST /api/peer/private/export<br/>HMAC-SHA256 signed
 A-->>B: Payload Fernet chiffré
 Note over B: Déchiffrement + indexation dans Meilisearch (base publique)<br/>hash_source="Peer - Nom"
 end

Transfert de dump (DuckDB / Meilisearch)

sequenceDiagram
 participant B as Instance B (source)
 participant A as Instance A (cible)

 Note over B: 1. B crée un dump DuckDB ou Meilisearch
 B->>B: db_dump_create (Redis lock)
 B->>B: CHECKPOINT + copie fichier / Meilisearch dump

 Note over A,B: 2. A génère un token de téléchargement
 A->>B: POST /api/peer/db/{type}/dumps<br/>HMAC-SHA256 signed
 B-->>A: Liste des dumps disponibles

 A->>B: POST /api/peer/db/{type}/download<br/>Avec token + signature
 B-->>A: Fichier dump chiffré Fernet

 Note over A: 3. A restaure le dump
 A->>A: db_dump_restore (Redis lock)

Le transfert de dump complète la sync incrémentale en permettant le transfert de snapshots complets de bases DuckDB ou Meilisearch entre pairs. Voir Sauvegarde DuckDB pour les détails techniques.

Avantages

  • Couverture étendue

    Les torrents d'une instance deviennent accessibles aux autres

  • Sécurité cryptée

    HMAC-SHA256 + Fernet (AES-128) + protection anti-rejeu

  • Sync incrémentale

    Seul le delta (nouveaux items) est transféré

  • Transfert de dump

    Snapshots complets DuckDB et Meilisearch transférables entre pairs, en complément de la sync incrémentale

  • Rate limiting

    Chaque clé a ses propres limites configurables

  • Bidirectionnel

    Chaque instance peut exporter et importer

Sections détaillées