skip to content

How does replication.policy.separator work, what is its default, and why must it be consistent across an MM2 deployment?

level: middleimportance: should knowfreq 45%

answer

  1. default = dot '.'
  2. sourceAlias<sep>topic
  3. policy both writes AND parses names
  4. must match across all workers
  5. empty separator invalid -> use Identity

basics

~20 s

replication.policy.separator is the character DefaultReplicationPolicy puts between the source cluster alias and the topic name. It defaults to a dot ('.'), so 'orders' becomes 'us-west.orders'. Changing it changes remote topic names; it must match everywhere or MM2 can't parse origins.

solid answer

~50 s

`replication.policy.separator` defines the delimiter DefaultReplicationPolicy inserts between the source cluster alias and the original topic name. Default is a dot, giving names like `us-west.orders`. You might override it (e.g. to `_` → `us-west_orders`) when a dot is awkward for downstream tooling, or because Kafka topic names allow only `[a-zA-Z0-9._-]` and you want a different convention. The catch: the separator is also how the policy PARSES a remote name to recover the source alias and the upstream topic — that's what powers cycle detection, offset-sync mapping, and `RemoteClusterUtils` lookups. So every MM2 worker, and any consumer-side tooling using the policy, must agree on the same separator. A mismatch means MM2 can't recognize a name as 'remote', breaking cycle detection and offset translation. Note: the empty string is not a valid separator with DefaultReplicationPolicy because origins would be unparseable.

go deeper

for a junior

Know it's the delimiter and defaults to a dot.

for a middle

Explain that it must be consistent everywhere and why a team might change it.

for a senior

Connect it to the policy's parse path (origin recovery, cycle detection, offset translation) and the empty-separator pitfall.

for a principal

Set naming conventions org-wide, account for downstream metric tooling, and choose separators that avoid ambiguity with real topic names.

## What it is `replication.policy.separator` is an MM2 configuration property consumed by `DefaultReplicationPolicy`. When the policy builds a remote (replicated) topic name, it concatenates: `<sourceAlias><separator><topicName>`. The separator's default value is `.` (a single dot). ``` source alias = us-west separator = . (default) topic = orders remote name = us-west.orders ``` ## Why change it Kafka topic names are restricted to the character class `[a-zA-Z0-9._-]` and max 249 chars. The dot is legal, but: - Some metrics/monitoring systems treat `.` as a hierarchy delimiter (e.g. Graphite), so a dot in topic names can mangle metric trees. - Internal compaction/cleanup of names, or organizational conventions, may prefer `_` or `-`. Setting `replication.policy.separator=_` yields `us-west_orders`. ## The bidirectional contract — why consistency is mandatory The policy does not only WRITE names; it also READS them. Methods like `topicSource(name)` and `upstreamTopic(name)` split a remote name on the separator to recover (a) which cluster it came from and (b) the original topic. This parsing drives: 1. **Cycle detection** — recognizing that a topic already originated elsewhere so it isn't looped back. 2. **Offset-sync / checkpoint translation** — mapping consumer offsets on a remote topic back to the source topic so consumers can fail over. 3. **Client utilities** — `RemoteClusterUtils` resolving the upstream topic for failover. If one worker writes `us-west.orders` (separator `.`) but another component is configured with separator `_`, the second can't parse `us-west.orders` as remote — it looks like a plain topic literally named `us-west.orders`. Cycle detection and offset translation silently break. Therefore the separator must be identical across all MM2 workers and any consumer-side tooling. ## Edge cases - **Empty separator**: not usable with DefaultReplicationPolicy because `us-westorders` is unparseable back into alias + topic. If you truly want no separator/prefix, use IdentityReplicationPolicy instead. - **Multi-character separators**: a separator string longer than one char is allowed but must still avoid producing ambiguous names; multi-hop replication nests prefixes using the same separator (`B.us-west.orders`). - **Separator collision with real topic names**: if an original topic name already contains the separator, parsing can be ambiguous — a reason teams sometimes pick an uncommon separator.

  • Why can't you set the separator to an empty string with DefaultReplicationPolicy?
    The policy parses remote names back into alias + original topic by splitting on the separator; with no separator the origin is unrecoverable, breaking cycle detection and offset translation. Use IdentityReplicationPolicy for truly unprefixed names.
  • Give a concrete reason to change the separator from a dot.
    Metrics systems like Graphite treat '.' as a hierarchy delimiter, so a dotted topic name fragments the metric tree; switching to '_' (us-west_orders) avoids that.

saying these in an interview costs you the question

  • Saying the default separator is '_' or '-' (it's '.')
  • Claiming you can mix separators across workers as long as data flows (it breaks origin parsing)
  • Thinking the separator only affects display, not cycle detection / offset sync

context

resolving links…