- The EV charging station sends its events to a topic named
EV_charging_topic. - Charging station metrics are published to a topic named
station_metrics_topic.
- A topic groups related messages logically. Think of each topic as a named stream for a particular type of data (device events, logs, user actions, metrics).
- You can create many topics to organize data streams; Kafka itself doesn’t impose a strict upper limit, but practical constraints arise from cluster resources and metadata overhead. Tens of thousands of topics may require broker tuning.
- Message categorization
- Topics let you group similar messages so consumers subscribe only to needed data streams.
- Proper topic design improves discoverability and simplifies downstream processing, analytics, and monitoring.
- Immutable, append-only logs
- Messages in a topic are written to an append-only log. Once a record is written it cannot be modified.
- This sequential, append-only storage preserves order within a partition (partitions are covered in the next lesson) and is important for use cases such as event sourcing and financial transactions.
- Retention controls how long records are kept (for example,
7dor up to a certain size like1GB). When retention thresholds are reached, older data is removed according to your configured policy.
Align retention settings with your application’s processing guarantees. If retention is too short, consumers might miss messages before they process them. If too long, you may incur unnecessary storage costs.
- Multi-consumer access
- Multiple consumers (organized as consumer groups) can read from the same topic independently. Each consumer group maintains its own offsets (read positions), so different applications can consume the same data without interfering with one another.
- This enables parallel analytics, monitoring, and real-time processing from a single event stream.
- Decoupled communication
- Producers write to topics and consumers read from topics. Producers and consumers are decoupled and do not need to be aware of each other or be online simultaneously.
- This decoupling supports scalable, asynchronous architectures where producers and consumers evolve independently.
- Replication (high availability)
- Topics (more precisely, topic partitions) are replicated across multiple brokers to provide fault tolerance and data availability.
- Replication ensures that if one broker fails, another broker holding a replica can continue to serve the data.
- We will cover replication details and leader/follower behavior in a later lesson.
Why topic design matters (short checklist)
- Keep related data together so consumers can subscribe to meaningful streams.
- Consider retention: balance consumer needs vs storage costs.
- Plan partitioning (next lesson) for throughput and ordering guarantees.
- Use replication to protect against broker failures.

- Apache Kafka documentation: https://kafka.apache.org/documentation/
- Kafka Concepts — Topics and Partitions: https://kafka.apache.org/documentation/#basic_concepts