A Kafka topic is a named destination that groups related messages. A producer names the topic when sending a message; a consumer subscribes to the topics it wants to read. A common design is one topic per message type, so services can select the data they need without sharing a single undifferentiated stream. section 2.2
Separate customer data by type
For a customer dashboard, one service sends financial transactions to a Transactions topic and another sends profile updates to a Profiles topic. A consuming service reads both to assemble a customer view. The separation makes each topic’s purpose clear while allowing one application to combine their data. section 2.2
Figure 2.3 Kafka topics, where each distinct type of message is segregated into its designated topic. Here, we have two services functioning as producers, each sending data to its respective topic. Additionally, a single consumer service subscribes to and consumes data from both topics.
Shows two producers sending distinct message types to separate topics, with one consumer reading both. section 2.2
A topic is divided into partitions, which enable parallel processing. Message order is guaranteed within a partition, not across an entire multi-partition topic. A message key can route related messages to the same partition when their order matters. Consumers pull messages from subscribed topics; within a consumer group, each partition is assigned to one consumer at a time. section 2.7 section 4.1
Choose retention for the job. A topic can delete older messages under a time or size policy. A compacted topic instead retains at least the latest message for each key, making it useful for current state, such as account balances or customer records. Compaction does not turn the topic into a quick key lookup: a consumer still reads the log sequentially to build its view. Older values may remain until cleanup, but their complete history is not guaranteed. section 2.0 section 2.5.1
Topic design follows business requirements. Decide whether related events need ordering, whether consumers need history or only current state, and how critical or sensitive the data is. Those answers shape keys, partitioning, retention, replication and access controls; Kafka is not automatically the right fit for every workflow. section 10.1.3
