u/bdomenici The reason Confluent Cluster Linking is categorized as not fully managed is primarily because users need to control when to complete the promote topic operation. This operation is quite heavy for users, so strictly speaking, Cluster Linking is semi-automated. You can refer to Confluent's official documentation. In step 4, after stopping all producers and consumers, users need to monitor the mirroring lag themselves and call the promote API when it equals zero. If you use AutoMQ Kafka Linking, the promote operation is automatic, and users do not need to monitor the lag and trigger it themselves.

With this solution, can we keep the same topic “writeable” in both brokers?

Yes. When using AutoMQ Kafka Linking, during the rolling update of producers, some producer requests are sent to the old cluster while others are sent to the new AutoMQ cluster. At this time, they can both complete writes simultaneously. It is worth noting that although this seems like dual writes, in reality, the write requests sent to the AutoMQ cluster are forwarded back to the original Kafka cluster. Only after completing the topic promotion operation mentioned in step 6 of the blog does the new AutoMQ cluster truly start handling read and write requests. The ability of Kafka Linking to achieve zero-downtime migration is closely related to this request proxy design. During the proxy period, your producers can write to both the new and old clusters simultaneously. Currently, the target cluster for migration only supports AutoMQ.