The Source
Notes from building Kilden — architecture, product decisions, and the occasional strong opinion.
Open devtools on almost any product and you can become its CEO — as far as analytics is concerned. Here's the boring cryptography that closes the hole, and the surprisingly delicate question of what to do with events that fail.
Fifteen years of building products leave you with scars, and ours all share an origin: data that entered a system through more than one door. This is the story of why Kilden only has one.
Who decides which users see your new feature? In Kilden, a hash function — with no memory, no assignment table, and no way to disagree with itself. And because flags sit on an event pipeline, they can target behavior, not just attributes.
The core of our web SDK is 7.7 KB gzipped — many cookie banners ship more JavaScript just to ask about cookies. What that budget actually buys: batching, retries, an offline queue, cross-subdomain identity, and a plan for the page's last 100 milliseconds.
For a while, some of our session replays played back as minutes of black screen. The recordings were fine. The bug was in a filename — and the fix is a rule about key design worth stealing.
Your analytics tool and your email tool disagree about what a user did today. Only one of them is wrong — good luck finding out which. Kilden's answer is structural: four products that physically cannot disagree, because they read the same stream.
Ask a queue vendor for exactly-once delivery and watch the asterisks multiply. It doesn't exist — but exactly-once effects do, and the whole trick is three decisions about where duplicates go to die.