#change-data-capture

Monolith to Service Architecture

Di chuyển từ kiến trúc monolith sang microservices cần áp dụng các pattern cụ thể thay vì viết lại toàn bộ. Bốn chiến lược chính gồm: Strangler Fig (dần dần chuyển lưu lượng qua API gateway), Parallel Run (chạy song song để kiểm chứng), Collaborator (thêm microservices mới mà không sửa core), và Change Data Capture (đồng bộ dữ liệu real-time bằng Debezium/Kafka Connect). Các pattern này hiệu quả nhất khi kết hợp theo trình tự trong quá trình chuyển đổi.

Lập trình viên nên đọc bài này để hiểu cách chuyển đổi từ kiến trúc monolith sang microservices một cách chỉnh xác, ít rủi ro và tối ưu hóa hiệu suất, không phải là một thay đổi đột ngột mà là một quá trình thuần túy, có kế hoạch với các mẫu thiết kế hiệu quả.

Debezium 3.6.1.Final Released

Debezium là nền tảng mã nguồn mở dùng để capture dữ liệu thay đổi (CDC) theo thời gian thực, hỗ trợ theo dõi các thao tác insert, update, delete trên cơ sở dữ liệu. Nó hoạt động bền vững và nhanh chóng, giúp ứng dụng phản hồi kịp thời mọi sự kiện ngay cả khi xảy ra lỗi.

Là người phát triển cần xây dựng hệ thống theo dõi thay đổi dữ liệu thực thời từ các cơ sở dữ liệu, Debezium sẽ giúp bạn tối ưu hóa việc đồng bộ hóa và xử lý sự kiện thay đổi nhanh chóng, giảm thiểu lỗi và tăng hiệu suất cho ứng dụng của bạn.

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.

Supabase Pipelines is now in Public Alpha

Supabase Pipelines ra mắt phiên bản Public Alpha với hỗ trợ thay đổi schema, tốc độ sao chép ban đầu nhanh hơn và biểu mẫu yêu cầu đích mới cho ClickHouse, Snowflake và DuckLake.

Là người phát triển cần tối ưu quy trình xử lý dữ liệu và tự động hóa công việc, Supabase Pipelines sẽ giúp bạn nhanh chóng tích hợp và chuyển đổi dữ liệu với hiệu suất cao, đặc biệt khi kết hợp với các nguồn lưu trữ như ClickHouse, Snowflake, hoặc DuckDB, giúp tiết kiệm thời gian và công sức trong quản lý dữ liệu.

The DynamoDB Connector is now in Tinybird Forward

Tích hợp DynamoDB vào Tinybird Forward thông qua file .connection và chỉ cần triển khai một lần. Giải pháp này giúp người dùng Classic hoàn tất quá trình di chuyển dữ liệu.

Lập trình viên cần đọc để biết cách tự động hóa chuyển đổi dữ liệu từ DynamoDB sang Tinybird Forward một cách nhanh chóng, tránh mất thời gian thủ công và tối ưu hóa quy trình chuyển đổi cho các dự án lớn.

Full CDC semantics land in the Iceberg output for Redpanda Connect

Iceberg giờ đây hỗ trợ đầy đủ CDC semantics, giúp data lakehouse phản ánh trạng thái thời gian thực của database nguồn thay vì chỉ dữ liệu từ batch đêm qua. Đây là tính năng mới nhất trong Redpanda Connect.

Lập trình viên cần đọc bài này để hiểu cách Redpanda Connect tích hợp CDC (Change Data Capture) với Iceberg để xử lý dữ liệu thay đổi thực thời, giúp họ tối ưu hóa việc đồng bộ hóa và phân tích dữ liệu thời gian thực mà không phụ thuộc vào các batch update cũ.

Detect CDC failures faster with AWS DMS

AWS DMS hỗ trợ cơ chế retry lỗi phục hồi (recoverable errors) bằng exponential backoff, nhưng mặc định có thể mất tới 30 phút mới thất bại. Bài viết hướng dẫn điều chỉnh bốn thiết lập quan trọng (RecoverableErrorCount, RecoverableErrorInterval, RecoverableErrorThrottling, RecoverableErrorThrottlingMax) để phát hiện lỗi CDC nhanh hơn, với cấu hình đề xuất giúp task thất bại sau ~225 giây. Ngoài ra, bài viết khuyến nghị thiết lập chính sách lỗi STOP_TASK trong giai đoạn cutover để ngăn chặn data drift, kết hợp cùng Amazon EventBridge và CloudWatch alarms theo dõi CDCLatencyTarget.

Lập trình viên cần hiểu cách tối ưu hóa AWS DMS để tránh lỗi ẩn giấu trong quá trình chuyển đổi dữ liệu, đặc biệt khi việc điều chỉnh các tham số như RecoverableErrorCount và RecoverableErrorThrottling có thể giúp phát hiện lỗi chỉ trong vài phút thay vì 30 phút, giúp bảo vệ dữ liệu và tránh rủi ro trong các cuộc chuyển đổi lớn.

The valley of webhooks

Tôi đã xây dựng ba hệ thống tiêu thụ webhook giống nhau tại ba công ty khác nhau. Lần thứ tư, tôi muốn tìm một giải pháp tổng quát hơn cho vấn đề này.

Một lập trình viên nên đọc bài này để khám phá cách tối ưu hóa lại cơ chế xử lý webhook—tránh sự lặp lại rắc rối khi phải tái phát triển từ đầu mỗi lần triển khai mới.

We'll End Up Where We Started. Except with Different Technology.

Chúng ta sẽ quay trở lại điểm xuất phát, nhưng với công nghệ khác biệt hoàn toàn.

Đọc bài này giúp lập trình viên hiểu rằng sự đổi mới kỹ thuật không ngừng diễn ra, nhưng bản chất của việc giải quyết vấn đề vẫn giữ nguyên—chỉ thay đổi công cụ và cách tiếp cận, nên phải luôn cập nhật kiến thức và kỹ năng để không bị lạc hậu trong ngành.

Writing Events Is All You Need

Ba định dạng lưu trữ dữ liệu (state-only, CDC, event sourcing) đạt lần lượt 28%, 59% và 85% trong bài benchmark 300 câu hỏi thuộc 5 lĩnh vực, cho thấy định dạng dữ liệu (event sourcing) đóng vai trò quan trọng trong khả năng reasoning của agent.

Một lập trình viên nên đọc bài này để hiểu cách event sourcing và CDC (Change Data Capture) không chỉ là các giải pháp lưu trữ dữ liệu mà còn là những phương pháp mạnh mẽ giúp xây dựng hệ thống có khả năng xử lý logic phức tạp, lý giải hành động của ứng dụng một cách chính xác và hiệu quả hơn so với các cơ sở dữ liệu chỉ lưu trạng thái.

Time Travel for Data: Traditional Workarounds vs. the Kurrent Way

Hệ thống dữ liệu truyền thống gặp nhiều hạn chế trong việc truy xuất dữ liệu theo thời gian. KurrentDB giải quyết vấn đề này nhờ kiến trúc dựa trên sự kiện (event-based), cho phép "du hành thời gian" dữ liệu một cách hiệu quả.

Là người viết mã, bạn sẽ hiểu rõ cách KurrentDB không chỉ phục hồi dữ liệu mà còn giải quyết vấn đề time travel một cách hiệu quả hơn so với các phương pháp truyền thống, giúp tối ưu hóa thời gian debug và bảo trì ứng dụng của bạn.

Real-Time CDC From PostgreSQL to Snowflake, Step by Step

Hướng dẫn từng bước thiết lập pipeline CDC real-time từ PostgreSQL sang Snowflake, đảm bảo khả năng tái sản xuất. Hầu hết các pipeline ETL Postgres-to-Snowflake hiện nay vẫn chạy theo phương pháp batch.

Lập trình viên muốn tự động hóa và tối ưu hóa dữ liệu thời gian thực từ PostgreSQL sang Snowflake mà không cần phụ thuộc vào các giải pháp ngoài bên thứ ba sẽ tìm hiểu cách triển khai CDC hiệu quả trong bài này.

Migrate self-managed PostgreSQL to Amazon RDS using the RDS console

Step-by-step guide for migrating a self-managed PostgreSQL database running on Amazon EC2 to Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL using the RDS console's auto-migration feature, powered by AWS DMS homogeneous data migrations. Covers three replication modes (full load, CDC only, full load + CDC), prerequisites including WAL configuration and IAM setup, a walkthrough of the migration process, verification steps, post-migration security hardening, and troubleshooting common errors like permission issues, WAL level misconfiguration, and replication slot exhaustion.

Running the Debezium Platform on AWS: PostgreSQL to Amazon Kinesis

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

Nếu bạn làm việc với hệ thống dữ liệu thực thời, đặc biệt là khi cần theo dõi và xử lý thay đổi dữ liệu PostgreSQL nhanh chóng và đáng tin cậy, Debezium Platform trên AWS sẽ giúp bạn tự động chuyển đổi và lưu trữ các thay đổi vào Kinesis, giúp ứng dụng của bạn phản ứng nhanh hơn và tránh mất bất kỳ sự kiện nào.

Online index migration and shard-scaling in OpenSearch with AOSC

Learn how Atlassian built AOSC, an OpenSearch plugin to reshape indices and scale their shards online.

Drag, drop, done: a visual composer for Redpanda Connect

A first look at the new visual Pipeline Builder for Redpanda Connect (preview), plus a roundup of recent CDC and connector updates.

Cache consistency: strategies to keep data fresh

Bộ nhớ đệm (cache) dần trở nên lệch so với cơ sở dữ liệu nguồn theo thời gian, do đó các chiến lược như cache-aside, write-through và đồng bộ theo sự kiện (event-driven sync) được áp dụng để duy trì tính nhất quán và chính xác của dữ liệu.

Lập trình viên cần đọc bài này để hiểu cách quản lý và đồng bộ hóa dữ liệu trong cache để tránh lỗi sai số do thời gian trễ giữa dữ liệu nguồn và cache, từ đó tối ưu hiệu suất và chính xác của ứng dụng.

Real-time Change Data Capture with Redpanda Connect and MySQL

A step-by-step tutorial on how to stream every insert, update, and delete from your database using MySQL and a faster, simpler alternative to Kafka Connect.

July 2026 newsletter

Welcome to the July 2026 ClickHouse newsletter, which will round up what’s happened in real-time data warehouses over the last month.

Introducing Apache Spark 4.2

Apache Spark 4.2 trong Databricks Runtime 19.0 bổ sung các tính năng mới như Auto CDC pipelines, lớp semantic bản địa, SQL không gian địa lý (GA), PySpark UDFs nhanh hơn và streaming thời gian thực.

Lập trình viên cần đọc bài này để khám phá những cải tiến mới trong Apache Spark 4.2, đặc biệt là Auto CDC (Change Data Capture) giúp tự động theo dõi và xử lý thay đổi dữ liệu trong pipeline, giúp tối ưu hóa quy trình ETL và bảo mật dữ liệu hiệu quả hơn.

Debezium Platform: Mid-Year Update (2026)

Debezium Platform lead Mario Vitale shares a mid-2026 status update covering recent improvements and upcoming work. Key additions include an enhanced configuration UI backed by a new component descriptor system (DDD-13), and integrated pipeline monitoring using OpenTelemetry with a built-in dashboard tracking throughput, replication lag, queue utilization, and snapshot progress. An AI chatbot POC is in progress but not yet ready for release. Upcoming work includes alerting on metric thresholds, Identity and Access Management with support for external identity providers, and host-based (bare-metal) deployment via Ansible — the last being contributed by a Google Summer of Code participant.

Fail back from Amazon RDS for Db2 to on-premises AIX Db2 using DMS

A step-by-step guide for setting up CDC-only reverse replication from Amazon RDS for Db2 back to an on-premises AIX Db2 instance using AWS DMS. The setup provides a temporary fail-back safety net during the post-cutover validation window (2–4 weeks), using a private-only network via AWS Direct Connect with no internet gateway. Covers IAM roles, VPC endpoints, security groups, source/target endpoint configuration, replication task settings, CloudWatch monitoring metrics, fail-back execution procedures, known limitations (LOB mode, DDL operations, sequences), and cost considerations.

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.

Building Kafka-Less Data Integration Pipelines with Debezium

Debezium now supports Kafka-less data integration pipelines via a JDBC sink in Debezium Server (DS) and the Debezium Management Platform (DMP). The tutorial walks through setting up a real-time data replication pipeline from PostgreSQL to MySQL using Docker, with no Kafka cluster required. Key configuration options like upsert mode, primary key handling, schema evolution, and delete propagation are explained. The same setup can be deployed on Kubernetes using the Debezium Operator CRD or managed through the DMP UI and REST API. Current limitations include no parallel processing (tasks.max > 1) and source-side filtering instead of topic-based consumer filtering.

What’s new in two – June 2026 edition

Redis announces two major June 2026 updates. First, Redis Data Integration (RDI) is now generally available in Redis Cloud on AWS, enabling continuous data sync from operational databases (including MongoDB and Snowflake preview) into Redis for real-time AI workloads and application acceleration. Second, the Flex tier gets a tunable RAM-to-Flash ratio (10–50% RAM), giving teams more control over cost vs. performance tradeoffs, with Flex pricing now extended to BYOC deployments.

Postgres vs MariaDB

Postgres and MariaDB are both open-source relational databases but serve different use cases. Postgres offers a richer type system (JSONB, arrays, geometric types), stronger SQL standards compliance, and a deep extension ecosystem (PostGIS, pgvector, Citus). MariaDB excels at MySQL wire-protocol compatibility, Galera multi-master replication, and optional ColumnStore analytics. Both are row-oriented OLTP databases that struggle with large-scale analytical queries. The post compares architecture, replication, JSON handling, and performance, then recommends offloading OLAP workloads to ClickHouse via CDC (logical replication for Postgres, binary log for MariaDB). Tinybird is presented as a managed ClickHouse layer that integrates with either database for sub-second analytical query latency.

Postgres vs Oracle

A technical comparison of Postgres and Oracle Database covering licensing costs, extension ecosystems, SQL dialect differences, HA architecture, and partitioning maturity. Both databases share the same OLTP ceiling for analytical workloads — once tables grow large, aggregation queries degrade performance. The recommended architectural pattern for both is CDC-based streaming to a columnar OLAP layer (ClickHouse/Tinybird), keeping the operational database for transactions. Includes a practical Oracle-to-Postgres SQL translation table and notes on PL/SQL migration challenges.

pg-cdc Frustratingly simple Postgres change data capture to AWS S3

pg-cdc is an open source tool that streams Postgres Write Ahead Logs (WAL) into typed, immutable Apache Iceberg tables on AWS S3. It registers entities in the AWS Glue Catalog and gates all reads via AWS Lake Formation tags, enabling AI agents, analysts, and query engines to consume governed data without database credentials or a JVM. Key properties include one-way data flow (no write-back risk), IAM-based authentication, column-level access control, and built-in time travel via Iceberg snapshots.

How CRED uses Amazon RDS Blue/Green Deployments at scale

CRED xây dựng một framework tự động hóa xung quanh Amazon RDS Blue/Green Deployments để quản lý 120+ cluster cơ sở dữ liệu sản xuất, hỗ trợ nâng cấp engine, scale instance, tối ưu storage và di chuyển pipeline CDC (AWS DMS, Debezium). Framework này đạt tỷ lệ thành công 100%, thời gian chuyển đổi trung bình 2 phút, mất 0 dữ liệu, không sự cố sản xuất và giảm 85% nỗ lực vận hành nhờ chuẩn bị trước (môi trường staging, chuyển traffic dần, xác nhận từ team ứng dụng).

Lập trình viên cần hiểu về Blue/Green Deployments trên RDS để tối ưu hóa quy trình triển khai ứng dụng, giảm thiểu rủi ro và tự động hóa các bước chuẩn bị, giám sát, và rollback trong môi trường sản xuất lớn, đặc biệt khi quản lý nhiều cluster database phức tạp.

Slowly Changing Dimensions in Microsoft Fabric

Microsoft Fabric's Copy job now includes native SCD Type 2 support as a built-in write method, eliminating the need for custom PySpark notebooks or complex Dataflow Gen2 merge logic. When enabled, it automatically adds Valid_From, Valid_To, and Is_Current columns to the destination table, handles row expiration on updates, and soft-deletes removed records. The post explains when to choose Type 1 vs Type 2 (a business decision, not a tooling one), walks through the configuration steps, and details current limitations: connector support is limited to Azure SQL DB, Azure SQL MI, on-premises SQL Server, and Fabric Lakehouse tables; the destination table must be created by Copy job itself; column mappings cannot be changed after enabling SCD Type 2; and CDC must be enabled on the source. For cases requiring custom change-detection logic, unsupported connectors, or fine-grained surrogate key control, notebooks remain the better option.

Search Is How Agents See the World

Agents rely on search as their primary interface to the world, but stale search results are a correctness problem rather than just a UX annoyance. The core challenge is maintaining computed search documents (denormalized entities assembled from joins, aggregates, pricing logic, and embeddings) as underlying source systems change. Batch reprocessing introduces lag; hand-rolled CDC pipelines are brittle and complex. Materialize addresses this by letting teams define computed entities as SQL views that are continuously maintained as inputs change, then propagating entity-level before-and-after diffs downstream. A companion open-source tool, Perfect Embedding, sits as a Kafka Connect SMT between Materialize and the search index, regenerating vector embeddings only when the fields that drive semantic meaning actually change.

Manage long-running transactions for AWS DMS performance

Long-running transactions are a common but overlooked cause of rising CDC source latency in AWS DMS migrations. When a transaction stays open, DMS must buffer all subsequent changes until it commits, causing latency to climb from seconds to hours. This post explains how DMS processes transactions, how to diagnose latency spikes, and provides ready-to-use bash monitoring scripts for Oracle, PostgreSQL, MySQL, and SQL Server. The scripts detect transactions exceeding a configurable threshold (default 15 minutes), send alerts via Amazon SNS, enforce TLS/SSL connections, retrieve credentials from AWS Secrets Manager, and filter false positives. A step-by-step Oracle demo shows the full workflow from DMS task setup to alert receipt. Scheduling via crontab enables continuous proactive monitoring.

Migrate MySQL to PostgreSQL: Data Types & SQL Rewrites

A practical walkthrough for migrating from MySQL to PostgreSQL, covering the full process: schema assessment, data type mapping (AUTO_INCREMENT, ENUM, unsigned integers, zero dates), SQL dialect rewrites (backticks, LIMIT syntax, IFNULL, GROUP_CONCAT, ON DUPLICATE KEY), stored procedure porting to PL/pgSQL, validation strategies, and low-downtime cutover using CDC. Includes copy-paste before/after SQL examples for common MySQL-isms and a comparison of migration tools (DBConvert, pgloader, AWS DMS).

Debezium 3.6.0.CR1 Released

Debezium 3.6.0.CR1, the first candidate release for the 3.6 milestone, introduces several enhancements: off-heap memory management for table history and schemas using RocksDB, a 75% reduction in memory allocation and 31–42% CPU overhead reduction in the MySQL connector's poll path, Spanner Omni compatibility, a monitoring REST API and multi-panel dashboard in Debezium Platform, and JDBC sink support in Platform. Oracle connector improvements include better diagnostics for missing archive logs, a unified JDBC driver version, exponential back-off for XStream attach retries, deferred transaction creation until first DML, and filtering of PRIVATE redo thread logs in RAC environments. Bug fixes address a KafkaSchemaHistory recovery race condition, PostgreSQL varbit column handling, Vitess timestamp processing, NanoTimestamp overflow for extreme dates, and CockroachDB temporal type alignment. A total of 44 issues were resolved.