Loading page
About this tool
Build a consistent Kafka topic naming convention from domain, entity, event type and version, with legality and collision checks.
A Kafka topic naming builder composes a topic name from ordered segments — message type, domain, entity, event type and schema version — and validates the result against the rules the broker actually enforces: a 249-character limit, the legal charset [a-zA-Z0-9._-], the reserved "__" prefix, and the dot-versus-underscore collision Kafka rejects at creation time. It also derives the matching retry, dead-letter, consumer-group and ACL-prefix names so a whole topic family stays consistent.
Open Kafka Topic Naming Builder on AltFTool — it loads instantly in your browser.
Provide your input — an image, text, or data.
Let the tool analyze or generate the result.
Review, refine, and reuse the output wherever you need it.
Length, charset, reserved prefix and the metric-namespace collision are validated, not assumed.
Main, retry tiers, dead-letter, consumer group and ACL prefix are derived from the same segments.
A schema version segment lets a breaking change ship as a new topic instead of a broken consumer.
A topic name may be up to 249 characters, may contain only ASCII letters, digits, dot, underscore and hyphen, and cannot be empty, "." or "..". The 249 limit exists because the log directory on disk is named "<topic>-<partition>" and must fit inside the usual 255-character filesystem limit.
Kafka's metrics namespace replaces dots with underscores, so "a.b" and "a_b" would report under the same metric name. The broker therefore treats them as colliding and refuses to create the second topic. Pick one separator for the whole cluster and never mix them.
Only if one cluster genuinely serves more than one environment. If dev, staging and production each have their own cluster, an environment segment is dead weight that also breaks MirrorMaker-style replication where the same name should exist on both sides.
Put a version segment such as v1 at the end of the name and treat a backwards-incompatible schema change as a new topic — producers dual-write to v1 and v2 until every consumer has moved, then v1 is retired. Compatible changes (adding an optional field) stay on the same topic and are handled by schema registry compatibility rules.