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

Co-authored-by: roldanbob <23705736+roldanbob@users.noreply.github.com>
Signed-off-by: Alvar Viana Gomez <alvigo92@gmail.com>

Author: AlvarVG

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

@@ -265,7 +265,7 @@ The results show that default configurations already deliver stable, predictable
 Optimizing table structures will often yield greater benefits than tuning Debezium itself.
 3. *Treat the database as the primary throughput limiter.* The benchmark shows that Debezium Server can keep up with MySQL in near real time and that overall throughput is bounded by database's write capacity.
 Performance efforts should therefore focus first on the database before attempting to optimize the CDC layer.
-4. *Scale architecture complexity only when necessary.* Kafka, Kubernetes and distributed CDC topologies are powerful but introduce non-trivial operational overhead. For lightweight or well-bounded workloads, Debezium Server alone is often sufficient and easier to operate.
+4. *Scale architectural complexity only when necessary.* Kafka, Kubernetes and distributed CDC topologies are powerful but introduce non-trivial operational overhead. For lightweight or well-bounded workloads, Debezium Server alone is often sufficient and easier to operate.
 More complex architectures should be adopted only when clear scalability, availability or integration requirements justify them. 
 
 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.