Change Data Capture — biến changelog của DB thành stream

TL;DR: CDC (Change Data Capture) đọc transaction log nội bộ của database — WAL (Write-Ahead Log) ở PostgreSQL, binlog (binary log) ở MySQL — và phát mọi INSERT/UPDATE/DELETE thành stream sự kiện để hệ phái sinh (search index, cache, warehouse) nhận và đồng bộ. Log-based CDC như Debezium đạt lag 100–500ms sau commit; polling định kỳ 10 giây có lag tối thiểu 10 giây, bỏ sót DELETE, và tốn CPU source database. Pitfall căn bản: dual-write — ghi database rồi ghi Kafka riêng, crash giữa hai bước → DB commit nhưng event mất → bất nhất âm thầm. Giải pháp: Transactional Outbox — ghi event vào bảng outbox cùng transaction, Debezium đọc CDC từ đó.

Đội kỹ thuật của một nền tảng thương mại điện tử cần giữ đồng bộ ba hệ phái sinh với database PostgreSQL chính: Elasticsearch cho tìm kiếm sản phẩm, Redis cho cache giỏ hàng, và Redshift cho báo cáo doanh thu. Ban đầu họ dùng polling — một tác vụ cron chạy mỗi 10 giây:

-- Poll bang orders tim thay doi moi
SELECT * FROM orders WHERE updated_at > :last_poll_time

Trong vài tuần đầu, polling chạy ổn. Rồi ba sự cố liên tiếp xuất hiện: (1) lag 10 giây khiến Elasticsearch hiển thị sản phẩm đã hết hàng; (2) khi sản phẩm bị xoá khỏi PostgreSQL, Elasticsearch không nhận được tín hiệu vì DELETE không để lại updated_at; (3) DBA thêm bảng inventory nhưng quên cột updated_at — toàn bộ thay đổi của bảng đó biến mất. Khi mở rộng lên 120 bảng, tải polling ngốn hơn 40% CPU database vào giờ cao điểm, với độ trễ tích luỹ lên nhiều giờ.

Bài này giải thích vì sao CDC đọc transaction log thay vì poll bảng, ba cách triển khai có gì khác nhau, và hai pitfall nghiêm trọng nhất khi đưa CDC vào sản xuất.

1. Analogy — sổ nhật ký giao dịch vs kiểm kê định kỳ

Hình dung một kho hàng cần biết lượng tồn kho mọi lúc. Có hai cách:

Cách một — kiểm kê định kỳ (polling): nhân viên cứ 10 phút lại ra kho đếm số lượng từng mặt hàng trên kệ. Biết được tổng tồn kho tại thời điểm đếm, nhưng không biết chuyện gì xảy ra giữa hai lần. Nếu một thùng hàng bị xuất kho và không để lại dấu vết trên kệ, lần đếm tiếp theo vẫn không biết.

Cách hai — nhật ký giao dịch (CDC): mọi hoạt động nhập-xuất-điều chỉnh đều được ghi ngay vào sổ kế toán khi phát sinh, theo thứ tự thời gian. Muốn biết tồn kho, đọc sổ. Không có thay đổi nào bị bỏ qua — kể cả xuất nguyên pallet.

2. CDC là gì — đọc transaction log thay vì poll bảng

Database quan hệ như PostgreSQL và MySQL không chỉ lưu dữ liệu trong các bảng. Trước khi ghi bất kỳ thay đổi nào xuống file dữ liệu chính, database ghi bút toán vào một transaction log phụ trợ — gọi là WAL (Write-Ahead Log) ở PostgreSQL và binlog (binary log) ở MySQL. Log này phục vụ hai mục đích: phục hồi sau crash (recovery) và đồng bộ sang replica (replication).

CDC khai thác hạ tầng đã có sẵn này: thay vì poll bảng với SELECT ... WHERE updated_at > ?, nó đọc trực tiếp WAL/binlog và phát mỗi entry thành một event.

Mỗi entry trong WAL chứa đủ thông tin để tái dựng sự kiện:

# Minh hoa WAL entry (PostgreSQL logical replication)
table:    orders
op:       UPDATE           -- INSERT | UPDATE | DELETE
lsn:      0/1A2B3C4       -- Log Sequence Number: vi tri trong WAL
before:   {id: 42, status: "pending", amount: 159000}
after:    {id: 42, status: "paid",    amount: 159000}

Điểm then chốt: WAL ghi trước khi commit xuống storage chính, và giữ cả ba loại thay đổi — INSERT, UPDATE, DELETE — với giá trị trước và sau (before/after). Polling SELECT chỉ thấy trạng thái hiện tại của hàng còn tồn tại trong bảng, không thấy gì đã bị DELETE và không có before-value cho UPDATE.

3. Ba phương pháp CDC — nên chọn cái nào?

Có ba cách triển khai CDC, mỗi cách đọc thay đổi từ database theo cơ chế khác nhau:

Polling (query-based): tác vụ định kỳ chạy SELECT ... WHERE updated_at > :watermark. Đơn giản nhất, không cần cấu hình gì trên database. Nhưng bỏ sót DELETE, cần cột updated_at trên mọi bảng, và lag bằng interval poll.

Trigger-based: database trigger ghi thay đổi vào bảng phụ change_log; CDC đọc từ đó. Bắt được DELETE, nhưng trigger chạy trong cùng transaction với thay đổi → tăng tải trực tiếp trên database nguồn; mỗi bảng cần 3 trigger (INSERT/UPDATE/DELETE); schema phức tạp hơn.

Log-based (đọc WAL/binlog): Debezium (hoặc Maxwell, Kafka Connector) đọc WAL/binlog qua giao thức replication. Không cần schema change, không cần trigger, lag thấp nhất, bắt đủ INSERT/UPDATE/DELETE với before/after value.

4. Log-based CDC với Debezium — flow thực tế

Debezium là open-source CDC framework chạy trên Kafka Connect. Mỗi connector lắng nghe WAL/binlog của một database và đẩy thay đổi vào Kafka topic tương ứng.

flowchart TB
    APP["Application"] -->|"INSERT/UPDATE/DELETE"| DB["PostgreSQL (source DB)"]
    DB -->|"ghi WAL truoc commit"| WAL["WAL / binlog (append-only replication log)"]
    WAL -->|"Debezium doc log qua replication protocol"| DBZ["Debezium connector"]
    DBZ -->|"publish event co before+after"| KAFKA["Kafka topic: orders.changes"]
    KAFKA -->|"consume"| ES["Elasticsearch (search index)"]
    KAFKA -->|"consume"| REDIS["Redis (cache)"]
    KAFKA -->|"consume"| DW["Redshift (warehouse)"]

Throughput mặc định của Debezium đạt 5.000–15.000 events/s mỗi connector; sau khi tuning lên 30.000–80.000 events/s; khi initial snapshot (đồng bộ lần đầu toàn bộ dữ liệu) đạt 100.000–500.000 rows/s. JSON serialize gốc nặng gấp 3–5 lần Avro — team có data volume lớn thường chuyển sang Avro kèm schema registry.

Mỗi event Debezium đẩy lên Kafka gồm: tên bảng, kiểu thao tác (INSERT/UPDATE/DELETE), trường before (giá trị trước), trường after (giá trị sau), và lsn — Log Sequence Number xác định vị trí chính xác trong WAL. Consumer downstream dùng thông tin này để cập nhật Elasticsearch, Redis, hay Redshift theo cách riêng của từng hệ.

5. Đồng bộ hệ phái sinh bằng CDC — worked example

Quay lại nền tảng thương mại điện tử. Sau khi chuyển từ polling sang Debezium, pipeline hoạt động như sau:

# Worked example: don hang 42 chuyen sang trang thai "paid"

# Buoc 1: Application ghi vao PostgreSQL (mot transaction duy nhat)
BEGIN;
  UPDATE orders SET status = 'paid', paid_at = NOW() WHERE id = 42;
COMMIT;

# Buoc 2: WAL da ghi thay doi (flush tai commit); Debezium doc sau commit
#   WAL entry: table=orders op=UPDATE
#     before: {id: 42, status: "pending"}
#     after:  {id: 42, status: "paid"}

# Buoc 3: Debezium doc WAL, phat event len Kafka topic "orders.changes" (lag 100-500ms)

# Buoc 4: Ba consumer group nhan event doc lap
#   - elasticsearch-sync: update document id=42 trong index "orders"
#   - redis-cache:        invalidate cache key "order:42"
#   - warehouse-sink:     append row vao Redshift table "order_events"

Điều quan trọng: application chỉ ghi một nơi (PostgreSQL), không cần biết có bao nhiêu hệ downstream đang nghe. Khi team thêm hệ phái sinh thứ tư (ví dụ Typesense cho full-text search), họ chỉ cần tạo consumer group mới trên Kafka topic đã có — không đụng application.

6. Pitfall tổng hợp

❌ Pitfall 1: Dual-write — ghi DB rồi ghi Kafka riêng

Pattern hay gặp nhất là sau khi ghi database, code gọi thêm kafkaProducer.send(event) riêng. Nếu ứng dụng crash sau khi database commit nhưng trước khi gửi Kafka, database có record mới nhưng Elasticsearch không biết. Bất nhất âm thầm — không có exception nào được throw, không có alert nào từ Kafka.

❌ SAI — dual-write: hai ghi doc lap, khong co atomicity
   db.save(order)                      -- commit ok
   kafkaProducer.send(orderEvent)      -- crash o day -> event mat vinh vien
   => PostgreSQL co record, Kafka khong co event
   => Elasticsearch mai mai khong biet don hang 42 da "paid"

✅ Giải pháp — Transactional Outbox: thay vì ghi Kafka trực tiếp, ghi event vào bảng outbox trong cùng transaction với dữ liệu chính. Debezium đọc CDC từ bảng outbox và đẩy lên Kafka. Tính nguyên vẹn (atomicity) do PostgreSQL đảm bảo: hoặc cả orders lẫn outbox được commit, hoặc cả hai rollback.

✅ DUNG — Transactional Outbox
BEGIN;
  UPDATE orders SET status = 'paid' WHERE id = 42;
  INSERT INTO outbox (event_type, payload)
    VALUES ('order.paid', '{"id":42,"status":"paid"}');
COMMIT;
-- Debezium doc CDC tu bang outbox -> phat len Kafka
-- Atomicity: ca hai commit hoac ca hai rollback. Khong bao gio lech.

❌ Pitfall 2: Schema change vỡ consumer downstream

Khi DBA đổi tên cột user_id thành customer_id trong PostgreSQL, Debezium hiểu đây là sự kiện drop cột cũ + add cột mới. Consumer đang đọc field user_id từ event sẽ nhận null hoặc gặp lỗi deserialization — ngay lập tức, với mọi message từ thời điểm ALTER.

❌ SAI — rename column truc tiep
ALTER TABLE orders RENAME COLUMN user_id TO customer_id;
=> Debezium: drop "user_id" + add "customer_id"
=> Consumer expect "user_id" -> nhan null hoac crash

✅ DUNG — expand-contract migration (5 buoc an toan)
Buoc 1: ADD COLUMN customer_id (ca hai cot ton tai song song)
Buoc 2: Cap nhat consumer chap nhan ca hai field
Buoc 3: Backfill customer_id = user_id
Buoc 4: Consumer chuyen han sang doc "customer_id"
Buoc 5: DROP COLUMN user_id (sau khi xac nhan khong ai dung nua)

Schema registry (Confluent Schema Registry) kiểm tra tương thích tự động và reject schema mới nếu phá vỡ hợp đồng: BACKWARD (mặc định) cho phép consumer nâng cấp trước đọc được cả dữ liệu schema cũ; muốn bảo vệ consumer cũ đang chạy khỏi dữ liệu schema mới thì dùng FORWARD. Nên dùng Avro hoặc Protobuf thay JSON thuần khi pipeline CDC vào sản xuất.

7. 📚 Deep Dive

8. Liên hệ các bài khác

• M2 — Log-based broker (bài 02): CDC biến thay đổi trong database thành event → Kafka giữ event đó trong log chỉ-append → nhiều consumer group (Elasticsearch, Redis, Redshift) đọc độc lập. CDC là phần "upstream" nạp dữ liệu vào Kafka; log-based broker là "downstream" vận chuyển.
• Bài 02 — Event Sourcing: event sourcing lưu mọi thay đổi như chuỗi event bất biến ngay trong application — tương đương thiết kế ở tầng ứng dụng những gì CDC làm ở tầng hạ tầng. Bài sau giải thích khi nào chọn event sourcing thay CDC và vì sao hai kỹ thuật hay kết hợp với nhau.
• Bài 03 — CQRS: CDC thường là cơ chế đồng bộ từ write model sang read model trong kiến trúc CQRS. Read model (Elasticsearch, Redis) cập nhật theo stream event từ CDC thay vì đọc trực tiếp write model.
• M1 — Tư duy batch (bài 01): batch reprocess cả lịch sử từ input bất biến; CDC reprocess được nhờ Kafka retention — chạy lại consumer từ offset cũ. Cùng triết lý: derived data dựng lại được từ nguồn bất biến (WAL/log).

9. Tóm tắt

• CDC đọc transaction log của database (WAL ở PostgreSQL, binlog ở MySQL) và phát mọi INSERT/UPDATE/DELETE thành event stream — không poll bảng, bắt được DELETE và before/after value.
• Log-based CDC (Debezium): lag 100–500ms sau commit; throughput mặc định 5.000–15.000 events/s mỗi connector; không thêm tải lên source DB; không cần schema change. Là lựa chọn mặc định cho sản xuất.
• Ba phương pháp: polling (đơn giản, bỏ sót DELETE, lag bằng interval), trigger-based (bắt DELETE nhưng tăng tải source DB, hiếm dùng), log-based (khuyến nghị: lag thấp nhất, không tăng tải, đầy đủ nhất).
• Dual-write là anti-pattern nguy hiểm: ghi DB + ghi Kafka riêng → crash giữa hai bước → bất nhất âm thầm. Giải pháp: Transactional Outbox — ghi event vào bảng outbox cùng transaction, Debezium đọc từ đó.
• Schema change (rename/drop cột) làm vỡ consumer downstream. Dùng expand-contract migration (5 bước) và schema registry với backward compatibility.
• CDC là nền để đồng bộ hệ phái sinh: application chỉ ghi một nơi (source DB), mọi downstream (Elasticsearch, Redis, Redshift) là derived data cập nhật tự động qua event stream từ Kafka.

10. Tự kiểm tra

Bài tiếp theo: Event Sourcing — lưu chuỗi sự kiện thay vì trạng thái