Introduction
A topic is more than a name passed to a producer. Its partitions organize the event log, its replicas describe stored copies, and its retention settings govern how long stored records remain eligible for keeping. Reading progress belongs to consumers and is a separate concern.
You will create two topics, inspect their metadata, give both an explicit retention policy, and then change only one. This isolates the meaning of a topic-specific override without waiting for real deletion or changing broker-wide configuration.
The prepared single broker is ready and the two topic names are independent of earlier labs. Basic terminal use is enough; no Python or Java programming is required. One replica is appropriate for this one-broker learning environment. Use the Terminal.
Create Two Topics and Read Their Metadata
In this step, you will compare two explicit partition counts. Start in your workspace:
cd /home/labex/project
--bootstrap-server supplies the prepared broker address. Create orders-retained with two partitions and orders-control with one. Both use one replica because this environment contains one broker:
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders-retained --partitions 2 --replication-factor 1
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders-control --partitions 1 --replication-factor 1
List the topics and save each description. The shell's > creates a local file or replaces its previous contents:
kafka-topics.sh --bootstrap-server localhost:9092 --list
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders-retained > /home/labex/project/output/orders-retained-description.txt
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders-control > /home/labex/project/output/orders-control-description.txt
cat /home/labex/project/output/orders-retained-description.txt
cat /home/labex/project/output/orders-control-description.txt
Find PartitionCount: 2 versus 1 and ReplicationFactor: 1 in both. Each partition has a leader entry. A leader broker identifier is not the partition count, and two partitions do not imply two broker machines.
A topic can have several partitions on the same broker. A replica factor describes copies of each partition across brokers, rather than independent copies for each consumer. Next, you will change storage retention without changing either of those properties.
Give Each Topic an Explicit One-Day Retention Override
In this step, you will distinguish an inherited default from a topic-specific setting. kafka-configs.sh manages configuration resources. --entity-type topics chooses topic resources, while --entity-name chooses the one topic affected. --describe normally shows topic overrides; an absent override does not mean the broker has no default.
Inspect the retained topic before changing it:
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --describe
retention.ms is a duration in milliseconds. One day is 24 × 60 × 60 × 1000 = 86400000 milliseconds. --alter --add-config sets that named override. Set the same explicit policy independently on both topics:
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --alter --add-config retention.ms=86400000
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-control --alter --add-config retention.ms=86400000
Read their actual overrides and save the observations:
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --describe > /home/labex/project/output/retained-one-day-config.txt
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-control --describe > /home/labex/project/output/control-one-day-config.txt
cat /home/labex/project/output/retained-one-day-config.txt
cat /home/labex/project/output/control-one-day-config.txt
Find retention.ms=86400000 for each named topic. A client can also print configuration-source or sensitivity details; those details and formatting can vary.
Retention is a broker storage policy, not an instruction to erase a record as soon as a consumer reads it. Record age and log-segment cleanup determine deletion eligibility and timing; the duration is not a promise that a specific message disappears at an exact instant. This exercise checks the configured override rather than waiting for cleanup.
Change Only One Topic and Confirm the Boundary
In this step, you will give orders-retained two days while keeping orders-control at one. Predict which metadata should change: the retained topic's retention override, with both partition counts and replica factors unchanged.
Two days is 172800000 milliseconds. Apply that value only to the named retained topic:
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --alter --add-config retention.ms=172800000
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --describe > /home/labex/project/output/retained-final-config.txt
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-control --describe > /home/labex/project/output/control-final-config.txt
cat /home/labex/project/output/retained-final-config.txt
cat /home/labex/project/output/control-final-config.txt
Expect retention.ms=172800000 for orders-retained and retention.ms=86400000 for orders-control. The shared broker address does not make a topic override global.
Describe the retained topic once more:
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders-retained
It should still have two partitions and one replica. Changing retention did not create a new topic, add partitions, copy consumer progress, or consume any events. You have verified both the intended change and the unaffected neighboring topic. Next, keys will connect order identities to partitions.
Summary
You created topics with explicit partitions and replicas, inspected their metadata, and applied retention overrides in milliseconds. Changing one topic left the other unchanged, separating topic storage policy from consumer progress. Next, you will route related events with keys and inspect their partition-local offsets.
