Recommended settings for Kafka Internal Topics after upgrade to 1.0
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
When upgrading Apache Kafka to version 1.0 or higher, it's important to optimize the settings for internal topics to ensure stability, performance, and durability of your Kafka cluster. Internal topics in Kafka, such as __consumer_offsets and Kafka Streams internal topics, play a crucial role in the operation and efficiency of Kafka.
Understanding Internal Topics in Kafka
Internal topics in Kafka are used for:
- Broker coordination: Used by brokers to manage cluster metadata and configurations.
- Offset tracking: The
__consumer_offsetstopic stores offsets for each topic-partition that consumers have read. This is crucial for maintaining consumer state across different sessions. - Kafka Streams: Topics like
__transaction_stateare used to manage Kafka Streams application states and transactional messaging.
Recommended Settings for Internal Kafka Topics Post-Upgrade
After upgrading to Kafka 1.0, some configurations and defaults have changed or been improved. Below are the recommended settings that should be considered for internal topics:
1. Topic Replication Factor
For all internal topics, the replication factor should be set according to the number of broker nodes in your cluster to ensure high availability. A common practice is to use at least a replication factor of 3 for fault tolerance.
2. Cleanup Policies
For the __consumer_offsets topic, a compacted cleanup policy is recommended. This helps in maintaining only the latest offset commit per partition while preventing the topic from growing indefinitely.
For other internally created topics like those used in Kafka Streams, a combination of deletion and compaction might be recommended depending on the use case.
3. Segment Configuration
Configuring the segment size and time can help manage the log cleanup process more efficiently, especially in high-throughput environments. Suitable segment sizes and roll out times minimize the overhead during log compaction and cleanup.
4. Retention Settings
For __consumer_offsets, because it uses log compaction, the retention time setting does not apply as for other topics. For Kafka Streams internal topics, configure retention settings based on how long you need to retain stateful information.
5. Min ISR (In-Sync Replicas)
Setting min.insync.replicas to at least 2 ensures that data is written to at least two replicas before an acknowledgment is returned to the producer, enhancing data durability.
Ensuring Smooth Upgrade and Configuration
When upgrading, ensure that these settings are applied not only to newly created internal topics but also existing ones, particularly if they were created with less optimal default settings in older versions. This might involve re-creating topics or altering topic configurations dynamically.
Summary Table
| Setting | Recommended Value | Description |
| replication.factor | 3 | Ensures data is replicated across three brokers for fault tolerance. |
cleanup.policy for __consumer_offsets | compact | Maintains only the latest offsets, optimizing space. |
| segment.bytes | Specific to your throughput and storage needs | Controls the log segment file size. |
| segment.ms | Specific to your requirements | Controls the time after which a new log segment is rolled out. |
| retention.ms for Kafka Streams topics | At least 172800000 (2 days) or as per state retention needs | Determines how long data is retained for stateful operations in Kafka Streams. |
| min.insync.replicas | 2 | Ensures data durability by requiring at least two replicas to acknowledge writes. |
Additional Considerations
- Monitor and adjust: Post-upgrade, actively monitor your Kafka cluster and adjust configurations as necessary based on actual usage and performance metrics.
- Backup before upgrade: Always ensure data is backed up before applying significant configuration changes or upgrades.
Following these guidelines ensures your Kafka 1.0 deployment maintains robust, efficient, and resilient internal topic configurations, facilitating smooth operations and minimal downtime.
Related reading
- Reconnecting to Kafka with node-rdkafka is slow & inconsistent
- RecordTooLargeException in Kafka streams join
- Redis / RabbitMQ - Pub / Sub - Performances
- Redis Pub/Sub vs Rabbit MQ
- Recommended way to configure max_prepared_transactions in Postgres on Kubernetes
- Reconstructing the list of items from a space optimized 0/1 knapsack implementation
- Redis vs Kafka vs RabbitMQ for 1MB messages
- Redis Vs RabbitMQ as a data broker/messaging system in between Logstash and elasticsearch

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.