Namespace & Events Taxonomy

A four-level hierarchical taxonomy for events and namespaces, enforced automatically via CI/CD, replacing an ungoverned, one-Kafka-topic-per-event free-for-all.

6 mo
design to full CI/CD enforcement
↓
requests to manually add new namespaces
4
levels in the namespace hierarchy, plus an object-action naming convention for events

6 months to v1, plus v2 for exceptions

Month 1–2
Discovery: rounds of validation with product + data teams
Month 6
Ship v1: four-level taxonomy + CI/CD enforcement live
Post-launch
Ship v2: internal mapping tables added for edge-case exceptions

The four levels

Subject area
level 1

Category
level 2

Subcategory
level 3

object_action
level 4, event name

Two risks, and what happened

Risk	How it was handled	Result
Business viability. No naming guidance: one Kafka topic per event, sometimes shared across unrelated use cases. An operational scaling risk, not just a tidiness problem.	Several rounds of discussion and validation with product and data teams. A business-needs-based structure, designed to survive org changes.	Fewer requests to manually add new namespaces. Product teams identify the area of impact of their events faster.
Feasibility. Multiple teams had already diverged into inconsistent, ad hoc conventions, so the taxonomy had to be retrofit-compatible.	Enforced through CI/CD validation, with internal mapping tables to handle exceptions without breaking production topics mid-migration.	Data governance enforcement became automated instead of relying on manual review.

My role. Owned the taxonomy design decision to ground it in business needs rather than team names, so it would survive reorgs, and made the call to enforce via CI/CD rather than documentation alone.

What came next. This taxonomy later became the foundation the Events Salad Bar tool was built on top of.

Product leader with a data scientist past · Zapier, Clearbit, HubSpot

Product doc: ale-cabrera.com/portfolio/taxonomy