One pipeline, four products

Your analytics tool says the user churned. Your email tool just sent them a "congrats on upgrading" campaign. Only one of them is wrong — and you'll spend an afternoon in two admin panels finding out which, because each vendor keeps its own copy of your users and the sync job between them has opinions.

The standard stack buys analytics, flags, campaigns and session replay from four vendors, integrates them four times, then pays a fifth vendor to shuttle user data between the other four. Kilden's bet is that all four are views over the same stream — and that the hard part isn't any single product. It's the small set of data decisions that let one stream serve them all without the products stepping on each other.

One enriched stream, many consumers

After ingestion and identity resolution, every event lands on a single enriched stream, keyed by the person it belongs to. Everything downstream is just another consumer:

Adding a product to Kilden doesn't mean a new data path. It means a new consumer group on a stream that already exists — with per-person ordering already guaranteed by the partition key. The four products can't disagree about what happened, because "what happened" exists in exactly one place.

The decisions that make it hold

Events are immutable; persons are mutable. An event freezes its properties at the moment it happened — what plan the user was on then, not now. Profile traits live on the person and update freely. Every consumer relies on this split: analytics never rewrites history, and campaigns read current traits at decision time. One append-only stream, one mutable profile store, never confused for each other.

The envelope is typed; the letter is not. The event envelope — ids, timestamps, keys, enrichment metadata — is a strict, versioned schema. The properties inside are opaque JSON, schema-less by design, because product teams ship new events daily and a pipeline that needs a schema migration per new property would never keep up. Infrastructure validates the envelope; products interpret the letter.

Dedup at the edges, not in the middle. The pipeline is at-least-once end to end. Instead of chasing exactly-once in transit, every edge absorbs duplicates: the analytics table is a ReplacingMergeTree keyed by the event's client-generated UUID, and the campaign side claims uniqueness in Postgres before acting. Duplicates are a non-event, so retries can be aggressive everywhere else.

Merges resolve at query time. When two identities turn out to be the same human, Kilden doesn't rewrite millions of stored events to the surviving person — overrides are applied when queries run. Rewriting history in an append-only store is where data corruption stories come from.

The payoff

The features nobody has to build twice: a funnel chart and an email campaign that count events the same way, flags that target "did X twice this week" without an export pipeline, replays already linked to the person analytics knows. In a four-vendor stack, every one of those is an integration project with a sync-lag bug tracker. Here they're the default state — one stream, four products, no glue, and no afternoon lost to figuring out which admin panel is lying.