Add follow-up section

Signed-off-by: AlvarVG <alvigo92@gmail.com>

Author: AlvarVG

_posts/2026-01-08-measuring-debezium-server-performance-mysql-streaming.adoc

@@ -270,3 +270,14 @@ More complex architectures should be adopted only when clear scalability, availa
 
 In summary, Debezium Server emerges as a simple, efficient and high-performance CDC solution that challenges the assumption that Kafka-centric or Kubernetes-based architectures are always required.
 For lightweight projects and streamlined deployments, it offers a compelling balance of maturity, simplicity and performance, delivering real-time change data capture while keeping infrastructure complexity to a minimum. 
+
+[id=follow-up]
+== What’s next?
+
+While the results presented above provide a clear view of Debezium Server behavior under default configurations, they also raise additional questions worth exploring in follow-up experiments:
+
+- Discover Debezium Server limits: improve this experiments architecture and configurations to discover what is the point where Debezium Server cannot recover from it.
+- Deploy Debezium with Kafka Connect: run this experiment with a distribuited and more complex architecture, using Kafka Connect to deploy Debezium.
+- Get involved with Snapshotting: we have miss one important Debezium feature, and Snapshotting deserves performance investigation.
+- Run different sets of workloads and databases: we have run this experiment against MySQL and used a uniform workload. 
+Include different database, connectors and workload will give us the complete vision of Debezium capabilities.