#apache-kafka

Debezium 3.7.0.Alpha1 Released

Debezium là nền tảng mã nguồn mở cho phép capture dữ liệu thay đổi (CDC) theo thời gian thực. Nó hoạt động bền vững và nhanh chóng, giúp ứng dụng phản hồi ngay lập tức các thao tác insert, update, delete từ cơ sở dữ liệu mà không bỏ sót sự kiện.

Nếu bạn làm việc với hệ thống dữ liệu thực thời, Debezium sẽ giúp bạn hiểu cách chuyển đổi và theo dõi thay đổi dữ liệu từ các cơ sở dữ liệu truyền thống sang các hệ thống stream hoặc event-driven, tối ưu hóa hiệu suất và độ tin cậy cho ứng dụng của bạn.

Eligible Leader Replicas (ELR) in Kafka 4.1: What You Need to Know

Kafka 4.1 giới thiệu ELR (Eligible Leader Replicas) cùng KIP-966 nhằm giải quyết vấn đề "Last Replica Standing", bảo vệ dữ liệu đã cam kết khỏi mất mát khi hệ thống tắt không sạch.

Lập trình viên cần hiểu về ELR trong Kafka 4.1 để tối ưu hóa hệ thống phân tán, tránh mất dữ liệu khi xảy ra sự cố không được kiểm soát, đặc biệt khi triển khai ứng dụng yêu cầu độ tin cậy cao.

Kafka's log compaction corrupts data. Here's how we fixed it

Apache Kafka có lỗ hổng trong cơ chế log compaction khiến dữ liệu bị hỏng do xung đột giữa compaction và replication, gây ra bốn vấn đề: dữ liệu đã xóa tái xuất hiện, giao dịch bị hủy hiện dưới dạng đã commit, dữ liệu đã commit bị ẩn, và consumers read_committed bị đóng băng partition. Redpanda Streaming khắc phục bằng giao thức compaction phối hợp, sử dụng các cặp offset (MCCO/MTRO, MXFO/MXRO) để đảm bảo tombstones và transaction markers không bị xóa trước khi tất cả replicas xử lý xong. Lỗi này có thể tái hiện trên Kafka phiên bản 3.9 đến 4.2 bằng Docker Compose.

Lập trình viên cần đọc bài này để hiểu cách giải quyết vấn đề lỗi race condition trong log compaction của Kafka, giúp tránh mất dữ liệu và bảo đảm tính nhất quán khi xử lý các trường hợp đồng bộ hóa dữ liệu trên nhiều broker.

AWS Glue Schema Registry is now available in ten more AWS regions

AWS Glue Schema Registry đã mở rộng sang thêm 10 vùng AWS, nâng tổng số vùng hỗ trợ lên 20.

Lập trình viên xử lý dữ liệu hoặc xây dựng hệ thống tích hợp dữ liệu nên đọc để hiểu cách mở rộng AWS Glue Schema Registry sang nhiều vùng AWS hơn, giúp tối ưu hóa quy trình quản lý và kiểm soát dữ liệu trong các môi trường đa vùng, giảm chi phí và tăng tính linh hoạt cho các ứng dụng của họ.

Karafka 2.6 and Web UI 1.0: Laying the Groundwork for Kafka Queues

Karafka 2.6 và Karafka Web UI 1.0 ra mắt với nhiều cải tiến như Declarative Topics DSL tách biệt, dynamic worker pool scaling, lag compensation cho partition tạm dừng lâu, cùng API offsets mới. Phiên bản này chuẩn bị nền tảng cho Kafka Share Groups (KIP-932) thông qua tái cấu trúc internal consumer-group. Web UI 1.0 bổ sung bảo mật CSRF header, giám sát poll interval và hiển thị worker runtime. Cả hai dự án đều có khoảng 55 bản sửa lỗi.

Nếu bạn đang phát triển ứng dụng sử dụng Kafka với Karafka và muốn tương thích với các tính năng tương lai như Kafka Share Groups, hãy đọc bài này để hiểu cách tổ chức lại mã nguồn và cách chuyển đổi nhẹ nhàng từ phiên bản 2.5 sang 2.6.

The Complete Guide to Message Queues and Event Streaming: Building Scalable, Reliable, and Real-Time Distributed Systems

Message Queues (hàng đợi tin nhắn) và Event Streaming (luồng sự kiện) là hai công nghệ cốt lõi giúp xây dựng hệ thống phân tán có khả năng mở rộng, đáng tin cậy và thời gian thực. Chúng hoạt động dựa trên nguyên tắc xử lý bất đồng bộ, đảm bảo giao tiếp giữa các thành phần hệ thống diễn ra hiệu quả.

Nếu bạn đang phát triển hệ thống phân tán cần độ tin cậy, khả năng mở rộng và phản ứng thời gian thực, bài này sẽ giúp bạn hiểu cách sử dụng queu tin nhắn và luồng sự kiện để xây dựng giải pháp hiệu quả.

Scaling StreamHub: Transitioning from Kinesis to Kafka for 145 Billion Daily Events

Atlassian's engineering team shares how they scaled StreamHub from 22 billion to 150 billion daily events by migrating from Amazon Kinesis to Apache Kafka via AWS MSK. The post details why Kinesis hit its limits (shard costs, retention constraints, consumer throughput), how Kafka Tiered Storage with S3 cut infrastructure costs, and the six critical operational challenges encountered at scale — including broker network saturation, S3 request rate storms during retention changes, managed control plane unavailability during AZ failures, and slow scaling operations during incidents. Solutions include intentional over-provisioning, ingress rate limiting, Kafka client quotas, cluster sharding with failover runbooks, and companion regions for compliant regional failover.

Kafka for High Availability in Practice: Patterns with Red Hat Streams for Apache Kafka

Tìm hiểu cách cấu hình Kafka đạt độ sẵn sàng cao trong thực tế thông qua replication, rack awareness, Cruise Control và MirrorMaker 2 với Red Hat Streams.

Lập trình viên cần đọc bài này để hiểu cách triển khai tích hợp cao độ cho hệ thống Kafka bằng các giải pháp thực tế như phân tán dữ liệu, giám sát tự động và sao chép đồng bộ giữa các cluster, giúp tăng khả năng chịu lỗi và phục hồi nhanh trong ứng dụng sản phẩm.

The Dual Write Problem in AI Feature Pipelines

Vấn đề "Dual Write" xảy ra khi một sự kiện nghiệp vụ cần cập nhật đồng thời hai hệ thống, dẫn đến thách thức về tính nhất quán dữ liệu trong kiến trúc AI.

Một lập trình viên cần đọc bài này để hiểu cách giải quyết vấn đề đồng nhất hóa dữ liệu khi một sự kiện kinh doanh cần cập nhật hai hệ thống khác nhau, giúp tránh tình trạng dual write inconsistency—lỗi thường gặp trong các pipeline AI, ảnh hưởng đến độ tin cậy và hiệu suất của hệ thống.

AutoMQ: What If Kafka Didn’t Have to Carry Its Own Luggage?

AutoMQ giới thiệu cách triển khai trên Kubernetes (kind) cục bộ, kiến trúc dựa trên S3, và hoạt động như một storage engine tương thích với Kafka.

Lập trình viên muốn tối ưu hóa ứng dụng Kafka trên Kubernetes sẽ tìm hiểu AutoMQ để tiết kiệm tài nguyên và giảm chi phí bằng cách sử dụng lưu trữ S3 thay vì bộ nhớ trong máy chủ, giúp cải thiện hiệu suất và độ bền.

From REST to Events: Coordinating Microservices with Kafka in Go

Bài viết hướng dẫn xây dựng hệ thống backup theo mô hình event-driven sử dụng microservices viết bằng Go, nơi các service giao tiếp qua Apache Kafka.

Là người phát triển Go, bạn sẽ tìm hiểu cách sử dụng Kafka để thay đổi cách giao tiếp giữa các microservice, giúp hệ thống trở nên linh hoạt hơn và giảm thiểu phụ thuộc vào REST, đặc biệt khi cần xử lý các sự kiện thời gian thực.

Real-Time AI Pipelines: Building a Kafka + Kubernetes + Databricks Stack for Agentic AI Systems

Bài viết giới thiệu cách xây dựng hệ thống AI thời gian thực bằng sự kết hợp giữa Kafka, Kubernetes và Databricks để triển khai các hệ thống AI agent, ví dụ như tự động bổ sung hàng tồn kho cho nhà phân phối.

Lập trình viên phát triển hệ thống AI cần đọc để hiểu cách kết hợp Kafka với Kubernetes và Databricks để xây dựng một ống dẫn xử lý thời gian thực hiệu quả, giúp các hệ thống AI agent hoạt động nhanh chóng và đáng tin cậy trong các ứng dụng quy mô lớn như tự động hóa chuỗi cung ứng.

Welcome to the Production Grade ML Systems Series!

Bài viết giới thiệu loạt bài về hệ thống Machine Learning (ML) đạt tiêu chuẩn sản xuất do Zuu Crew – Học viện ML đầu tiên tại Sri Lanka – biên soạn, tập trung vào huấn luyện mô hình ML.

Một lập trình viên nên đọc bài này vì nó không chỉ giới thiệu cách xây dựng mô hình ML đơn giản mà còn tập trung vào cách chuyển mô hình thành hệ thống sản xuất thực tế, giúp bạn hiểu rõ về quy trình triển khai, quản lý và tối ưu hóa mô hình trong môi trường sản xuất.

Beyond the Hardware Hub: How ALC Taipei Turned Computex 2026 into a Milestone for the Apache Way

ALC Taipei đã tạo nên dấu ấn tại Computex 2026 bằng cách giới thiệu gian hàng chuyên biệt đầu tiên về dự án mã nguồn mở ASF, thu hút hơn 30 thành viên tham gia trong suốt năm ngày và giới thiệu các dự án như Apache Kafka, Airflow, Ozone cùng nhiều dự án khác. Nhóm đang triển khai kế hoạch dài hạn nhằm thúc đẩy chính sách công về mã nguồn mở tại Đài Loan, hợp tác với trường đại học đào tạo phương pháp đóng góp upstream, và mở rộng cộng đồng OpenSource4You. Họ cũng đặt mục tiêu tham dự các sự kiện Community Over Code tại Bắc Kinh và Glasgow, đồng thời dự kiến tổ chức một sự kiện tương tự tại Đài Bắc.

Những lập trình viên muốn xây dựng tương lai công nghệ bền vững và có ảnh hưởng thực sự nên đọc bài này để khám phá cách một cộng đồng nhỏ nhưng quyết tâm của ALC Taipei đã biến Computex 2026 thành một bước đột phá trong việc vận động và định hình phong cách làm việc mở (Apache Way) trong ngành công nghệ.

Confluent for Startups

Confluent vừa vinh danh Upvest (Berlin) là "Startup về Data Streaming tiêu biểu EMEA 2026". Upvest tận dụng nền tảng Confluent để vận hành hệ thống đầu tư nhúng theo thời gian thực, đáp ứng các yêu cầu pháp lý khắt khe và mở rộng cơ sở hạ tầng fintech hiện đại cho các định chế tài chính hàng đầu.

Nếu bạn đang xây dựng hoặc phát triển hệ thống xử lý dữ liệu thời gian thực cho ngành tài chính, Confluent for Startups sẽ giúp bạn hiểu cách tối ưu hóa công nghệ stream data để đáp ứng yêu cầu phức tạp của các quy định và mở rộng hiệu quả cho các ứng dụng fintech.

Building Service Topology at Scale: Architecture, Challenges, and Lessons Learned

Netflix đã xây dựng pipeline phân tán ba giai đoạn cho bản đồ dịch vụ thời gian thực, giải quyết các thách thức như backpressure, node nóng và mở rộng Kafka.

Những kinh nghiệm từ Netflix về thiết kế và vận hành hệ thống phân tán lớn như pipeline ba giai đoạn thực sự có thể giúp bạn hiểu rõ cách xử lý các vấn đề như tải trọng không cân bằng, nóng điểm và tối ưu hóa Kafka trong ứng dụng quy mô lớn của riêng mình.

Tableflow: Turn Kafka Topics into Iceberg Tables

Confluent Tableflow is a managed Confluent Cloud feature that automatically materializes Apache Kafka topics as Apache Iceberg or Delta Lake tables, eliminating the need for custom ETL pipelines. It converts Kafka topic data (Avro, JSON Schema, Protobuf) into Parquet files, generates Iceberg/Delta Lake metadata, and publishes tables to catalogs like AWS Glue or Unity Catalog. The post walks through a step-by-step setup using Confluent Cloud, Amazon S3, and AWS Glue, covering cluster creation, schema registration, S3 bucket setup, IAM role configuration, and enabling Tableflow on a topic. Schema evolution is handled automatically via Confluent Schema Registry. Once materialized, tables can be queried from Snowflake, Databricks, AWS Athena, Trino, and BigQuery.

Redpanda vs Kafka vs Confluent: An Honest Comparison

A detailed comparison of Apache Kafka, Confluent, and Redpanda across performance, operational complexity, ecosystem maturity, and enterprise readiness. Redpanda's C++/Seastar thread-per-core architecture eliminates JVM GC pauses and delivers lower p99/p99.9 tail latencies, especially on NVMe hardware, and ships as a single binary versus Kafka's componentized stack. However, Kafka and Confluent win on ecosystem depth (120+ managed connectors, native Flink integration, decade of community tooling) and enterprise SLAs. The post also covers the emerging 'diskless Kafka' trend via KIP-1150, AutoMQ, and WarpStream (now Confluent-owned), noting that object-storage-native architectures may reshape the cost equation more than broker-level efficiency gains. Redpanda's BSL 1.1 license is flagged as a consideration for procurement teams. The recommendation is to run proof-of-concept benchmarks against actual production traffic rather than relying on vendor-published numbers.

Developing Real-Time Event Processing With Micronaut and Kafka Streams: A Step-by-Step Guide

A step-by-step guide to building a real-time word counting application using Micronaut and Kafka Streams in Java. Covers why this combination is effective (compile-time DI, no separate stream processing cluster), project setup with Docker Compose, Kafka Streams topology construction, REST API integration for message ingestion and querying, and common pitfalls like Jackson time serialization issues and null message values when using @KafkaClient. The same patterns apply to financial transactions, IoT data, or user behavior processing.

Your Kafka Infrastructure Just Became Optional

Snowflake announced two products at Summit 2026 that make the traditional Kafka-to-warehouse pipeline optional: Openflow (now GA), a managed integration service built on Apache NiFi with pre-built connectors for Kafka, MongoDB, BigQuery, and more; and Datastream, a Kafka-compatible streaming endpoint native to Snowflake that eliminates the need for a Kafka cluster entirely. Together they collapse the typical five-hop pipeline (Kafka → Zookeeper → Schema Registry → Kafka Connect → S3 → ETL) into a single step. The post covers when to keep Kafka vs. replace it, cost comparisons (typical mid-size Kafka setup runs $3K–$6.5K/month plus engineering overhead), deployment models (SPCS vs. BYOC), and key limitations including no autoscaling for the Kafka connector and Iceberg schema evolution not supported in Openflow.

Apache Pulsar vs Kafka: Comparing Modern Event Streaming Platforms

A structured comparison of Apache Kafka and Apache Pulsar covering architecture, scalability, storage, multi-tenancy, geo-replication, consumer models, and cloud-native deployment. Kafka uses a combined broker architecture with a mature ecosystem, while Pulsar separates compute and storage via Apache BookKeeper, offering built-in multi-tenancy and geo-replication. The post outlines when to choose each platform and common operational best practices.

Debezium 3.6 Release Summary

Debezium 3.6 is now generally available, delivering a broad set of new features, improvements, and breaking changes across the entire ecosystem. Key breaking changes include removal of MySQL's 'never' snapshot mode, deprecation of Oracle's 'redo_log_catalog' mining strategy, PostgreSQL enum values now returned in logical sort order, and MongoDB schema name adjustments for Avro compatibility. New features span all connectors: a new Docling SMT for AI/document workflows, off-heap RocksDB-based schema history storage, quantile metrics across all connectors, MySQL DDL parser migration to ANTLR Oracle grammar, Oracle LogMiner batch sizing rework for better performance, SQL Server set-based LSN-to-timestamp resolution, a new Amazon SNS sink, JDBC sink as a native Debezium Server sink, an incubating Apache Fluss sink, a new YashanDB source connector, a unified CLI, and extensive Debezium Platform improvements including integrated monitoring dashboards, OpenTelemetry support, and JDBC sink support.

Deep Dive into SASL PLAIN and SCRAM in Kafka: Login Modules and Config Hot-Reload

A deep dive into Kafka SASL authentication mechanisms — PLAIN and SCRAM — focusing on how different login modules (PlainLoginModule, ScramLoginModule, FileBasedLoginModule) handle credential storage and whether they support hot-reload without broker restarts. SCRAM stores credentials in cluster metadata (KRaft), enabling native hot-reload via Admin APIs. Static JAAS PLAIN requires broker restarts for credential changes, while file-backed PLAIN modules support hot-reload through periodic file watching. The post includes a concrete three-listener broker configuration example, scenario-based comparisons of each mechanism's behavior during credential updates, and production recommendations for zero-downtime credential rotation.

Scaling Java-Based Real-Time Systems: The Hidden Tradeoffs of Event-Driven Design

A detailed production retrospective on building a Java/Kafka-based cloud contact center platform handling 80k BHCC across 10k agents. The author documents five major failure modes discovered in production: async latency violating real-time contracts, cache mismatch across service instances, Kafka partition limits blocking horizontal scaling, cross-cluster deduplication adding 200ms+ latency, and blocking REST calls inside consumer threads causing 30+ minutes of consumer lag. Each problem is traced through its root cause and resolved solution, including a three-generation state management evolution from Kafka Global State Stores to local in-memory caches to Redis shared cache with a background recovery thread. JVM-specific concerns are addressed including Spring Boot startup overhead, GC pressure under high throughput, and the potential of JDK 21 virtual threads. The article concludes with five architectural decisions the author would make differently from day one.

Real-Time Fraud Detection & Financial Compliance

Confluent Cloud provides a real-time fraud detection platform built on Apache Kafka and Apache Flink, addressing the three core requirements for production-grade financial systems: security, resilience, and compliance. Security features include TLS encryption, BYOK, client-side field-level encryption (CSFLE), private networking, RBAC, OAuth 2.0, and SAML SSO. Resilience is backed by a 99.99% uptime SLA, multi-availability-zone deployments, and zero-downtime maintenance. Compliance coverage spans PCI DSS, SOC 2, GDPR, CCPA, DORA, FINRA, and other financial regulations. The post walks through a full production architecture covering transaction ingestion, stream processing, ML model scoring, case management, audit trails, and global fraud intelligence via cluster linking.

Stream Governance: Compliance for Data in Motion

Confluent's Stream Governance suite addresses the governance gap in real-time streaming architectures, where traditional tools designed for data at rest fall short. The suite includes Stream Catalog for data discovery and classification, Stream Lineage for end-to-end flow visualization, Schema Registry for enforcing data contracts, RBAC for access control, client-side field-level encryption (CSFLE), and client-side payload encryption (CSPE). These capabilities collectively address compliance requirements across PCI DSS, HIPAA, GDPR-style right-to-erasure (including cryptographic deletion via key destruction), operational resilience frameworks like DORA and APRA CPS 230, and financial reporting integrity. The core argument is that compliance should be an inherent property of the data stream itself rather than a manual checkpoint applied after the fact.

How to build a real-time fraud detection system

Bài viết hướng dẫn xây dựng hệ thống phát hiện gian lận theo thời gian thực bằng Tinybird và Retool, gồm 4 bước: thu thập luồng giao dịch (qua Kafka/Tinybird Events API), xử lý phân tích dữ liệu bằng SQL pipes, cung cấp kết quả qua HTTP API, và trực quan hóa trên dashboard. Tác giả cung cấp các truy vấn SQL mẫu để phát hiện hành vi đáng ngờ như giao dịch tốc độ cao, vị trí bất thường, hoặc hoạt động ngoài giờ, đồng thời đề cập xu hướng hiện đại như phát hiện bất thường bằng ML hay nền tảng streaming Apache Flink.

Lập trình viên phát triển hệ thống cần đọc để hiểu cách triển khai một giải pháp phòng ngừa gian lận thực thời bằng cách kết hợp công nghệ stream processing, SQL và API, từ đó tối ưu hóa hiệu suất và độ chính xác trong ứng dụng của mình.

My Experience with Kafka: A Cross-Region Event Bus for Hundreds of Microservices. Part 1

A retrospective on building a cross-region Kafka event bus spanning dozens of data centers across four continents, serving hundreds of microservices. Covers the rationale for running Kafka on Kubernetes, practical tips on disk I/O, Page Cache behavior, and JVM tuning, a comparison of Koperator vs Strimzi for broker management, mTLS-based authorization with HashiCorp Vault and ACLs managed via GitOps and ArgoCD, and five hard-won rules for stable bidirectional replication with MirrorMaker 2 including prefix enforcement, pull-model deployment, and traffic isolation.

Confluent: Data in motion

Batch customer data platforms can't capture user intent as it forms — by the time a nightly sync completes, the intent moment is gone. A streaming-native architecture built on Apache Kafka and Apache Flink handles the full spectrum of personalization latency windows, from sub-100ms real-time bidding to multi-day email campaigns, using the same four-job pipeline: connect, stream, process, and govern. An AI-native layer (Confluent Intelligence) sits on top, enabling streaming agents with MCP tool-calling, a real-time context engine for LLMs, and built-in ML functions (ML_PREDICT, AI_COMPLETE) for embedding, ranking, and generative copy — all running as Flink jobs with exactly-once semantics and full lineage. The guide covers three production patterns (retail product recommendations, media feed personalization, cross-channel cart abandonment orchestration), a five-capability vendor evaluation framework, and a three-phase rollout roadmap from streaming backbone to autonomous agentic personalization.

How to Eliminate Training-Serving Skew in MLOps (2026)

Training-serving skew — the divergence between features used during model training and those seen at inference time — silently degrades ML accuracy and doubles infrastructure costs. The solution is a unified kappa architecture: compute features once in Apache Flink, dual-write to an offline store (Apache Iceberg or Delta Lake) for training and an online key-value cache for serving. DoorDash measured a 35.7% feature-value mismatch in their dual-pipeline setup; Netflix replaced a $93M/year dual-pipeline backfill with a $2M/year kappa replay. The reference architecture covers Kafka ingestion via Confluent's Kora engine, serverless Flink with event-time watermarks and exactly-once semantics, Tableflow for automated Iceberg/Delta materialization, and Stream Governance for schema enforcement and lineage. A tooling comparison covers Databricks, SageMaker+Kinesis, Tecton, Feast, and Confluent, with a decision framework based on latency requirements, existing stack investment, and pipeline fragmentation. The post is authored by a Confluent employee and promotes the Confluent Data Streaming Platform throughout.