Schema evolution — đổi schema không downtime

TL;DR: Code thay đổi liên tục, nhưng dữ liệu sống lâu hơn code rất nhiều — bản ghi ghi hôm nay có thể được đọc bởi code của hai năm sau, và code mới triển khai hôm nay phải đọc được dữ liệu cũ. Schema vì thế phải tiến hoá mà không vỡ. Hai chiều tương thích: backward compatibility (code mới đọc được data cũ) và forward compatibility (code cũ đọc được data mới). Trong rolling upgrade — khi phiên bản cũ và mới chạy song song — bạn cần cả hai. Quy tắc an toàn: chỉ thêm field optional, không đổi nghĩa field cũ, không bỏ field bắt buộc; và dùng expand-contract để đổi cấu trúc qua nhiều bước thay vì một cú nhảy. Hiểu điều này để đổi schema mà không gây downtime.

Đội của bạn triển khai phiên bản mới của một service: thêm field phone vào User. Deploy không phải tắt-bật toàn bộ một lúc — cluster có 20 instance, hệ thống cuốn chiếu (rolling) từng cái một để không gián đoạn. Trong vài phút đó, một nửa instance chạy code mới (biết phone), nửa kia chạy code cũ (không biết phone). Một request đi qua instance mới ghi bản ghi có phone; ngay sau đó một instance cũ đọc bản ghi đó. Nếu code cũ sập khi gặp field lạ, bạn vừa gây lỗi cho người dùng — chỉ vì thêm một field.

Đây là vấn đề schema evolution: dữ liệu và code không đổi cùng lúc, nên các phiên bản phải đọc được dữ liệu của nhau. Bài này giải thích hai chiều tương thích, vì sao rolling upgrade cần cả hai, và quy tắc đổi schema an toàn — nối tiếp ý "field tag" từ bài 02.

1. Analogy — Biểu mẫu giấy qua các năm

Một cơ quan dùng tờ khai giấy. Năm nay họ in mẫu mới: thêm ô "email", bỏ ô "số fax". Nhưng trong ngăn tủ vẫn còn hàng nghìn tờ khai mẫu cũ đã điền, và nhiều nhân viên vẫn cầm mẫu cũ chưa kịp đổi.

• Nhân viên mới (code mới) cầm mẫu mới, nhưng phải xử lý được cả tờ khai cũ trong tủ (data cũ) — họ chấp nhận "tờ này không có ô email" thay vì vứt nó đi. Đó là backward compatibility.
• Nhân viên cũ (code cũ) gặp một tờ khai mẫu mới (data mới có ô email): họ phải bỏ qua ô lạ và vẫn xử lý phần mình hiểu, thay vì xé tờ giấy. Đó là forward compatibility.

Bí quyết để chuyển mẫu êm thấm: thêm ô mới thì để trống được (optional), đừng đổi ý nghĩa ô cũ (ô "ngày" vẫn là ngày, không bỗng thành "tháng"), và đừng đột ngột bỏ ô bắt buộc mà ai đó còn dựa vào.

2. Vì sao dữ liệu sống lâu hơn code

Một bản deploy thay code trong vài phút. Nhưng dữ liệu thì tích luỹ và tồn tại:

• Bản ghi ghi từ ba năm trước vẫn nằm trong database, vẫn được đọc.
• Message trong một queue có thể chờ giờ-tới-ngày trước khi được xử lý — bởi một consumer có thể đã lên phiên bản khác.
• Dữ liệu ở tầng cold (xem bài 01) sống nhiều năm; khi cần lấy lại, code đọc nó đã đổi nhiều thế hệ.

Truc thoi gian:
  code v1 --- deploy v2 --- deploy v3 --- deploy v4 -->
  data:   ghi v1 ...... van con ...... van duoc doc boi v4

=> code v4 PHAI doc duoc data ghi tu thoi v1 (backward compat)

Hệ quả: bạn không thể giả định "dữ liệu luôn khớp code hiện tại". Code mới phải đọc được mọi định dạng cũ còn tồn tại, và — trong lúc deploy — code cũ phải sống sót khi gặp định dạng mới.

3. Hai chiều tương thích

flowchart TB
  subgraph BACK["Backward compatibility"]
    NEWC["Code MOI"] -->|"doc duoc"| OLDD[("Data CU")]
  end
  subgraph FWD["Forward compatibility"]
    OLDC["Code CU"] -->|"doc duoc<br/>(bo qua field la)"| NEWD[("Data MOI")]
  end

Backward compatibility — code mới đọc data cũ. Đây là chiều dễ hơn và gần như luôn cần: khi nâng cấp, code mới phải xử lý được mọi dữ liệu đã ghi bởi các phiên bản trước. Code mới biết các định dạng cũ trông thế nào (vì nó là hậu duệ), nên chỉ cần xử lý "field này có thể vắng trong bản ghi cũ".

Forward compatibility — code cũ đọc data mới. Đây là chiều khó hơn: code cũ phải xử lý dữ liệu được ghi bởi phiên bản tương lai mà nó chưa từng biết. Mấu chốt là code cũ phải bỏ qua một cách lịch sự những gì nó không hiểu — gặp field lạ thì lờ đi, không sập. Field tag số (từ bài 02) giúp việc này: format binary cho code cũ "nhảy qua" tag chưa biết mà vẫn đọc được phần còn lại.

4. Quy tắc đổi schema an toàn

Ba quy tắc giữ cả hai chiều tương thích:

4.1 Thêm field thì phải optional (có default)

Thêm field mới không được làm bắt buộc. Nếu bắt buộc, code mới đọc bản ghi cũ (không có field đó) sẽ thiếu giá trị và lỗi — vỡ backward compat. Field mới phải có giá trị mặc định hoặc cho phép vắng.

OK  : them field `phone` optional, default rong
      - code moi doc data cu: phone vang -> dung default (OK backward)
      - code cu doc data moi: gap tag la -> bo qua    (OK forward)

VO  : them field `phone` BAT BUOC
      - code moi doc data cu thieu phone -> loi (vo backward)

4.2 Không đổi nghĩa field cũ

Một field đã tồn tại phải giữ nguyên ý nghĩa và kiểu. Đừng tái dùng field status (đang là chuỗi "active"/"inactive") thành số 0/1 — code cũ và code mới sẽ diễn giải cùng byte theo hai cách, ra kết quả sai mà không báo lỗi. Cần nghĩa mới thì thêm field mới, đừng đổi field cũ.

4.3 Không bỏ field bắt buộc (mà bên kia còn dựa vào)

Bỏ một field mà code cũ (hoặc consumer khác) vẫn đọc sẽ làm chúng thiếu dữ liệu → vỡ forward compat. Chỉ bỏ field khi chắc không còn ai đọc nó — và cách an toàn để đạt điều đó là expand-contract dưới đây.

5. Expand-contract — đổi cấu trúc qua nhiều bước

Khi cần một thay đổi không tương thích trực tiếp (đổi tên field, đổi kiểu, tách/gộp field), đừng làm trong một bước. Dùng expand-contract (còn gọi parallel change): mở rộng trước, dọn sau, qua nhiều lần deploy để luôn có một trạng thái mọi phiên bản đọc được.

Ví dụ: đổi name (một chuỗi) thành first_name + last_name.

EXPAND  (deploy 1): them first_name, last_name (optional).
        Code GHI ca name (cu) lan first/last (moi). Code DOC uu tien
        truong moi, fallback name. -> moi phien ban deu du data.

MIGRATE (nen): backfill du lieu cu -> dien first/last tu name.

CONTRACT (deploy 2): khi chac khong con ai doc `name`, ngung ghi
        va bo `name`. Chi lam khi MOI client da len phien ban moi.

flowchart LR
  E["EXPAND<br/>them field moi,<br/>ghi ca hai"] --> M["MIGRATE<br/>backfill data cu"]
  M --> C["CONTRACT<br/>bo field cu<br/>khi het ai doc"]

Ý cốt lõi: ở mọi thời điểm giữa các bước, dữ liệu có cả định dạng cũ lẫn mới, nên cả code cũ lẫn mới đều tìm được thứ chúng cần. Không có khoảnh khắc nào "data chỉ ở dạng một phiên bản không đọc được". Đây cũng chính là tinh thần migration ở Module 5 — schema migration: đổi cấu trúc database mà không khoá bảng hay gây downtime.

6. Pitfall — đổi kiểu hoặc bỏ cột một cú

WRONG (mot cu):
  deploy doi `age` chuoi -> so   -> cu va moi ghi/doc lech kieu -> vo

RIGHT (expand-contract):
  1. them `age_num` optional, ghi ca `age` (chuoi) lan `age_num`
  2. backfill `age_num` tu `age`
  3. khi moi client doc `age_num`, ngung ghi + bo `age`

7. 📚 Deep Dive

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

• Bài 01 — Vòng đời dữ liệu: dữ liệu ở tầng cold sống nhiều năm — chính nó buộc code mới phải backward-compatible với định dạng đã ghi từ lâu.
• Bài 02 — Encoding & serialization: field tag số của binary format là cơ chế kỹ thuật cho phép code cũ bỏ qua field lạ (forward) và code mới hiểu field vắng (backward).
• Module 5 — Schema migration: expand-contract áp dụng trực tiếp cho việc đổi cấu trúc bảng database (thêm/bỏ cột, đổi kiểu) mà không downtime.
• Module 10 — OLTP vs OLAP: pipeline ETL phải xử lý dữ liệu nguồn có nhiều thế hệ schema khác nhau — schema evolution là điều kiện để ETL không vỡ khi nguồn đổi.

9. Tóm tắt

• Dữ liệu sống lâu hơn code: bản ghi cũ vẫn được code mới đọc; code cũ trong lúc deploy vẫn gặp data mới.
• Backward compatibility = code mới đọc data cũ (chiều dễ, gần như luôn cần). Forward compatibility = code cũ đọc data mới (chiều khó, cần code cũ bỏ qua field lạ).
• Rolling upgrade cần cả hai chiều vì code cũ và mới chạy đồng thời, đọc/ghi cùng kho — thiếu một chiều là nửa cluster sập trong cửa sổ deploy.
• Ba quy tắc an toàn: thêm field phải optional có default; không đổi nghĩa/kiểu field cũ; không bỏ field bắt buộc mà bên kia còn dựa vào.
• Field tag số (binary format) là nền kỹ thuật: code cũ nhảy qua tag chưa biết, code mới dùng default cho tag vắng.
• Thay đổi không-tương-thích (đổi tên/kiểu, tách/gộp) phải làm bằng expand-contract: mở rộng (ghi cả hai dạng) → backfill → thu hẹp (bỏ dạng cũ khi hết ai đọc) — luôn có trạng thái mọi phiên bản đọc được.

10. Tự kiểm tra

Bài tiếp theo: Module 10 — OLTP vs OLAP: hai workload đối lập