Event Explorer

Caine Nielsen · August 14, 2026

I've always liked observability tooling — there's something satisfying about being able to throw an arbitrary query at a mountain of data and get an answer back in milliseconds. Event Explorer is my attempt at building the piece of that experience I find most interesting: a Lucene-style search box over a table of events that have no fixed schema at all, and making sure it stays fast even as that table grows past a million rows on nothing but my laptop.

Repo: github.com/cainenielsen/event-explorer

What it does

Under the hood, every event is just a free-form JSON body — a purchase, a login, a shipment, whatever. There's no owner_id column, no type column with a fixed enum. And yet the UI lets you type things like:

That last one is the scenario I actually designed the seed data around: a book event's owner_id and a lunch event's eater_id can hold the same person under two completely different key names. Typing a bare id turns up a handful of events scattered across several event types, out of a million rows — and it still comes back in milliseconds.

Stack

Why this was hard: making an unknown key fast to filter on

The core problem is that you can't pre-declare a column, or a normal index, for a JSON field you don't know exists yet. Everything interesting in this project is really just different answers to that one problem, stacked on top of each other.

The payload gets stored two ways: body keeps the original JSON, byte for byte, and attributes is that same JSON flattened into a Map(LowCardinality(String), String) — nested objects become dot-joined keys, every scalar leaf becomes one map entry. owner_id:usr_00042 and user.is_active:true actually query against that map, not against body and not through a JSON-parsing function.

On top of that sit three different kinds of ClickHouse data-skipping indexes, because the problems they solve are genuinely different: a set(100) index on the truly low-cardinality columns (event_type, source) that can guarantee a block doesn't match; Bloom filters on mapKeys()/mapValues() of the attributes map, since attribute keys and values are arbitrarily high-cardinality and Bloom filters degrade gracefully instead of failing outright; and a tokenizing Bloom filter (tokenbf_v1) on the raw body, which is what makes the "search any key" free-text query possible at all — there's no way to build a per-key index for a key you don't know about in advance, so instead I tokenize the raw bytes and treat every token as a candidate needle.

I didn't want to just assume all of this actually helped, so I checked it with EXPLAIN indexes = 1 against the live, seeded table: on a selective value, the token-based search pruned to 35 of 1235 granules, a measured ~6.5x wall-clock win. I also tried the tempting simplification of swapping that whole tokenize-and-rewrite approach for a plain body LIKE '%value%' — and rejected it, because LIKE with wildcards on both sides read all 1235 granules every single time on this ClickHouse version. Worth actually running the query instead of trusting the intuition that "it's basically the same index."

Architecture

Running it

Docker Compose does most of the work:

Then it's just localhost:8080, with interactive API docs at /docs.

Conclusion

Event Explorer is a small demo on the surface — a search box and a results table — but almost all of the actual work went into the six or seven layers underneath it that make an unknown JSON key just as fast to filter on as a real column would be. That's the part of backend work I enjoy most: not the CRUD, but figuring out exactly which mechanism is doing the work, and then actually measuring it instead of assuming.