Suppose a product management system needs to publish price changes so inventory and sales analysis can react independently. A Kafka topic gives those changes a named place to go. Producers publish records to the topic; consumers read them. Like a database table, a topic groups data about a subject, but it can also be viewed as a log that services read to build their own views. section 2.2 section 17.4.2
A practical name is products.prices.changelog. Create it before sending price updates. This starting configuration uses one partition and a replication factor of one to keep the exercise simple; it is not a demonstration of replicated fault tolerance. section 2.2
$ kafka-topics.sh \
--create \
--topic products.prices.changelog \
--partitions 1 \
--replication-factor 1 \
--bootstrap-server localhost:9092
Created topic products.prices.changelog.
The creation command names the topic, sets its partition and replication counts, and connects through a bootstrap server. If it fails, check that Kafka is running and that the topic does not already exist. section 2.2
One stream, independent readers
Send a price update such as “coffee pads 10” to products.prices.changelog with kafka-console-producer.sh. An inventory consumer can watch for new updates while a separate sales-analysis consumer starts with --from-beginning to read retained updates. Neither consumer needs to coordinate with the other. Kafka retains data for seven days by default, and retention can be configured so older records remain available. section 2.2 section 2.4
A topic is divided into partitions to parallelize processing; partitions can be replicated across brokers for resilience. Plan the partition count: it can be increased but not decreased. A client obtains metadata about a topic’s partition leaders before producing or consuming, so a production bootstrap configuration should not depend on one broker remaining available. section 1.3 section 3.3 section 7.4
