After this process, all servers will be aware of the latest set of internal topics and can cache internal topics in MedatadaCache. Thus, that KafkaApi can construct the metadata response with the information of all clients created internal topics by referring MetadataCache.
Internal topic behaviors
- topics `__consumer_offsets` and `__transaction_state` as system-defined internal topics,
- topics whose config contain `internal=true` as user-defined internal topics.
Below will be the Kafka default allowed operations for internal topics. However, Cluster admins admin might want to control the operations on internal topics using ACLs as they might be dangerous.
- Internal topic creation will be allowed.
- Internal topic deletion will be allowed except for` __consumer_offsets` and `__transaction_state`.
- Producing to internal topic partitions other than `__consumer_offsets` and `__transaction_state` will be allowed.
- Adding internal topics to transactions will be allowed.
Post ZK world
add restrictions using ACLs on user-defined internal topics depending on the actual user application logic.
|system-defined internal topics||user-defined internal topics|
Topic creation (ApiKeys.CREATE_TOPICS)
|Topic deletion (ApiKeys.DELETE_TOPICS)||forbidden||allowed|
|Add to transaction (ApiKeys.ADD_PARTITIONS_TO_TXN)||allowed||allowed|
For the metadata operation, user-defined internal topics will be treated in the same way as system-defined internal topics. For example, in the metadata request (`ApiKeys.METADATA`), broker will mark both user-defined internal topics and system-defined internal topics as `internal`.
To get the internal topic information, instead of using the static internal topic testing or implementing their own logic, clients can utilize KafkaAdminClients and make a MetadataRequest (ApiKey.METADATA).
Post ZK world
Compatibility, Deprecation, and Migration Plan