Sailhouse

Les topics sont les compartiments dans lesquels vos événements sont regroupés. Vous publiez un événement JSON dans un seul topic, identifié par un slug, et la plateforme le répartit vers chaque abonnement rattaché à ce topic. Les événements portent aussi des métadonnées, et c'est ainsi que la plateforme colle des trace IDs ou marque un événement déclenché par cron avec sa planification. Topics et abonnements sont les deux ressources de base, et tout le reste se construit dessus.

Sailhouse prend en charge les deux modèles de livraison. Un abonnement push envoie une requête POST vers votre endpoint quand un événement arrive, et attend une réponse 200 en 5 secondes. Un pull inverse la logique : votre worker demande les événements à son rythme, ce qui convient aux traitements lourds comme un cycle de facturation ou un résumé hebdomadaire. Vous choisissez par abonnement, donc un même topic peut alimenter en même temps un webhook temps réel et un worker par lots.

Les groupes d'attente sont la fonction qui rend le travail d'agents en parallèle réellement praticable. Vous remettez à la plateforme une liste d'événements à lancer et un topic à notifier à la fin ; Sailhouse les exécute et publie un événement quand tout le groupe a terminé. Sans cela, vous écririez des vérifications en double ou une boucle propice aux conditions de course du type « est-ce que tout est fini ? ». C'est le même schéma qu'un wait-group dans un langage de programmation, déplacé dans un système événementiel où les nouvelles tentatives ne génèrent pas d'appels en trop.

Sailhouse crée les ressources à la demande. Vous envoyez un événement dans un topic qui n'existe pas et la plateforme le crée avec le slug fourni, puis y stocke l'événement. Les abonnements pull se créent de la même façon, avec une fenêtre de temps allant jusqu'à 24 heures qui récupère tout ce qui est entré dans un topic sur cette période. L'objectif est de réduire les étapes de schéma entre l'écriture du code et la mise en ligne, ce qui compte quand vous itérez sur un agent.

Vous pouvez mettre du travail en file pour plus tard de deux manières. Les événements programmés fixent une heure sur un événement isolé ou sur un abonnement, pratique pour traiter un paiement 14 jours après une commande ou envoyer un rappel. Les cron jobs, aujourd'hui en bêta privée, lancent des événements dans un topic selon une planification répétée, toujours en UTC, pour des récapitulatifs quotidiens ou des calculs d'usage horaires. Les deux réutilisent le même modèle d'abonnement, donc il n'y a pas de planificateur séparé à apprendre.

Les filtres d'abonnement vous laissent garder des topics génériques tout en réduisant le bruit et le coût. Au lieu de découper un topic en une douzaine de topics étroits, vous filtrez à l'abonnement avec un chemin JSON, si bien qu'un consommateur ne voit que les événements qui l'intéressent. La plateforme prend aussi en charge la limitation de débit et la déduplication dans la même couche, là où vous placeriez des garde-fous contre les livraisons en double ou une rafale d'un éditeur qui s'emballe.

Sailhouse fournit des SDK maison pour TypeScript et JavaScript, Go, Python (bêta) et Rust (bêta), plus une CLI et une API REST pour tout le reste. Le volet observabilité couvre le traçage des événements : vous pouvez coller des trace IDs et suivre un événement dans le système. Comme c'est hébergé, les régions d'ingestion couvrent aujourd'hui Londres, Ashburn et San Jose, avec des données écrites de façon centralisée et chiffrées en transit et au repos.