Introduction

Using one Kafka topic per producer can be reasonable, but it is not a universal best practice. It usually optimizes for ownership and producer isolation, while topic-per-domain designs often optimize better for consumers and shared event streams.

What “Topic Per Producer” Means

In this design, each producing service owns its own topic.

Examples:

• 'billing-service writes to billing-events'
• 'inventory-service writes to inventory-events'
• 'shipping-service writes to shipping-events'

This is different from a topic-per-domain design where several producers may publish related event types into one stream such as orders or payments.

That difference matters because a Kafka topic is not just a label. It carries:

• partition count
• retention settings
• compaction policy
• ACLs
• schema expectations
• consumer subscription patterns

So the choice is architectural, not cosmetic.

Why Teams Like It

Topic-per-producer gives clear ownership boundaries.

Benefits include:

• each team owns its own stream
• retention can be tuned independently
• permissions map cleanly to service ownership
• one noisy producer does not clutter unrelated topics

Producer code stays simple:

1import java.util.Properties;
2import org.apache.kafka.clients.producer.KafkaProducer;
3import org.apache.kafka.clients.producer.ProducerRecord;
4
5Properties props = new Properties();
6props.put("bootstrap.servers", "kafka-1:9092,kafka-2:9092");
7props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
8props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
9
10KafkaProducer<String, String> producer = new KafkaProducer<>(props);
11producer.send(new ProducerRecord<>("billing-events", "invoice-42", "invoice-created"));
12producer.flush();
13producer.close();

Kafka itself does not care whether the topic boundary is producer-based or domain-based. The real question is whether the boundary serves the whole system well.

The Consumer Cost Appears Later

A topic layout that is convenient for producers can be awkward for consumers.

Many consumers care about business meaning rather than which service emitted the record. An analytics or audit consumer may want all order-related events, not one topic per team.

That can lead to:

• subscribing to many topics
• stitching several streams together downstream
• more schema coordination across topic boundaries

Regex subscription can make the mechanics easier:

consumer.subscribe(Pattern.compile(".*-events"));

But regex subscription does not solve the modeling problem. It only hides some subscription boilerplate.

Topic Count and Platform Overhead

A few extra topics are no problem. A large uncontrolled number of topics can become one.

Each topic adds:

• metadata overhead
• ACL management
• monitoring burden
• policy decisions for partitions and retention
• operational review cost

If a platform has hundreds of producing services, topic-per-producer can turn into thousands of topics faster than teams expect. That is not automatically wrong, but it requires governance.

Healthy topic-per-producer platforms usually standardize:

• naming conventions
• ownership metadata
• default partition counts
• retention defaults
• review rules for topic creation

Without that, topic sprawl becomes an operational problem.

Compare It With Topic Per Domain

Topic-per-domain usually serves consumers better because it groups events by business meaning.

A practical rule of thumb is:

• choose topic per producer when ownership, isolation, and independent lifecycle dominate
• choose topic per domain when shared business-event consumption dominates

Many real systems use a hybrid model. Some topics are internal producer-owned streams, while others are curated domain topics intended for broad cross-team use.

That hybrid model is often more realistic than trying to enforce one universal rule.

Plan for Evolution

Early topic designs rarely remain perfect forever. Teams often start with producer-specific topics because they are easy to reason about, then later add domain streams, aggregation topics, or derived topics as consumer needs grow.

That evolution is easier if:

• names are stable and meaningful
• schemas are versioned
• ownership is documented
• migration paths are planned

Assuming the first topic layout will never change usually makes later redesign more painful than it needs to be.

Common Pitfalls

The biggest mistake is optimizing entirely for producer convenience and only later discovering that consumers must join many narrow streams to answer one business question.

Another issue is letting teams create producer-owned topics without governance. The pattern works much better when naming, ownership, retention, and ACL rules are standardized.

People also often confuse service boundaries with event boundaries. A service boundary may define team ownership without being the best event-stream boundary.

Finally, topic count is neither irrelevant nor automatically disastrous. The real question is whether the platform can operate the chosen model cleanly.

Summary

• Topic per producer gives strong ownership and isolation, but it can increase consumer complexity and topic-management overhead.
• It often serves publishers better than consumers.
• Topic-per-domain is often better for shared business-event consumption.
• Many real Kafka platforms use a hybrid of producer-owned and domain-owned topics.
• Topic design should follow consumer needs and operational capacity, not only producer boundaries.