Auto-héberger Kilden
Kilden est construit pour être auto-hébergeable, et l’auto-hébergement sera documenté ici quand notre publication open source sortira. Pas de promesse de date — nous préférons le publier fonctionnel plutôt qu’annoncé.
Ce que vous feriez tourner
Section intitulée « Ce que vous feriez tourner »L’aperçu honnête. Kilden est une petite flotte de services sans état autour de quatre briques d’infrastructure — du streaming compatible Kafka, ClickHouse, Postgres, Redis, et un object storage compatible S3 pour le replay :
SDKs / provider webhooks / external sources │ ▼ capture ──► events_raw (keyed by distinct_id) │ ▼ enricher ──► Postgres (persons, identities) │ ▼ events_enriched (keyed by person_id) │ │ │ │ ▼ ▼ ▼ ▼ warehouse campaign CDP live tail writer matcher sync │ │ │ │ ▼ ▼ ▼ ▼ panel (websocket) ClickHouse journeys destinations (PG) → scheduler → dispatcher → email provider │ provider webhooks ──────┘ (re-enter through capture)Le session replay emprunte un chemin parallèle : les chunks d’enregistrement vont dans l’object storage, seuls des pointeurs d’environ 200 octets transitent par Kafka, et un indexeur construit l’index de sessions dans ClickHouse.
Les propriétés qui le rendent exploitable :
- Les services sont sans état — tout l’état vit dans les bases de données et les offsets des consommateurs, donc tout scale horizontalement et les redémarrages sont sans histoire.
- Livraison at-least-once avec des bords idempotents — chaque couche peut réessayer sans risque ; la déduplication par UUID générés côté client donne de l’exactly-once là où ça compte.
- Un seul chemin d’écriture — chaque événement entre par capture, donc il n’y a qu’une seule chose à sécuriser, rate-limiter et surveiller pour l’ingestion.
En attendant
Section intitulée « En attendant »Kilden Cloud est la version hébergée d’exactement cette architecture — même code, mêmes garanties. Tout le reste de cette documentation s’applique aux deux.