Naming, Ownership and Topic Hygiene

Topics are public APIs

Once other teams consume a topic, its name, key and schema are a contract. Use a consistent naming convention (for example <domain>.<entity>.<event>.v1 such as sales.order.placed.v1), name an owner team and document the schema, key meaning, retention and expected volume. Disable automatic topic creation in production so topics are created deliberately with chosen partitions and replication, and review or script topic changes (infrastructure as code). Delete unused topics, because each one costs storage and metadata. Use separate topics for different event types unless they must stay strictly ordered together.

A topic spec

Keep specs like this next to the code that creates the topic.

topic: sales.order.placed.v1
owner: team-orders@example.com
partitions: 12
replication_factor: 3
config:
  min.insync.replicas: 2
  retention.ms: 604800000      # 7 days
key: order_id                   # per-order ordering
value_schema: OrderPlaced (Avro, backward-compatible)
consumers: [billing, fulfilment, analytics]

Quick check: Why disable auto topic creation in production?

• So topics are created deliberately with proper partitions and replication
• Because it is slower
• Auto creation is illegal
• It uses more memory only