Get in touch
or send us a question?
CONTACT

Data Contract

Data Contract: Vì sao chỉ một thay đổi nhỏ có thể “làm sập” cả hệ thống?

Trong các hệ thống hiện đại (microservices, data pipeline, API-first), một vấn đề rất phổ biến nhưng thường bị xem nhẹ là:

Thay đổi cấu trúc dữ liệu mà không kiểm soát

Chỉ cần một service đổi format response — có thể kéo theo hàng loạt lỗi ở các hệ thống phía sau.

Đây chính là lý do Data Contract ngày càng trở nên quan trọng.


🚨 Vấn đề thực tế

Giả sử bạn có API trả về:

{
“user_id”: “123”,
“email”: “user@example.com”
}

Một ngày nào đó, team backend “refactor nhẹ”:

{
“id”: “123”,
“email”: “user@example.com”
}

Nghe có vẻ vô hại. Nhưng thực tế:

  • Frontend không đọc được user_id
  • Batch job fail
  • Analytics pipeline sai dữ liệu
  • Một số service downstream crash

👉 Tất cả chỉ vì đổi tên một field.


🧠 Data Contract là gì?

Data Contract là:

Cam kết rõ ràng về cấu trúc và ý nghĩa dữ liệu giữa các hệ thống

Nó định nghĩa:

  • Field nào tồn tại
  • Kiểu dữ liệu (string, number…)
  • Format (date, enum…)
  • Có bắt buộc hay không

Ví dụ:

{
“user_id”: “string (required)”,
“email”: “string (required)”,
“created_at”: “ISO8601 (optional)”
}

👉 Khi đã là contract:

  • Không được tự ý thay đổi breaking
  • Mọi thay đổi phải có kiểm soát

⚠️ Điều gì xảy ra nếu không có Data Contract?

  • Các team phụ thuộc chặt vào nhau
  • Mỗi lần release phải “hẹn giờ deploy”
  • Debug lỗi rất mất thời gian
  • Lỗi lan rộng (cascade failure)
  • Data sai nhưng không phát hiện ngay

Trong hệ thống lớn, đây gần như là “bom nổ chậm”.


🛠️ Cách áp dụng Data Contract trong thực tế

1️⃣ Định nghĩa schema rõ ràng

  • Dùng OpenAPI / JSON Schema / Protobuf
  • Public contract cho các team liên quan

2️⃣ Không thay đổi breaking trực tiếp

❌ Tránh:

  • Xóa field
  • Đổi tên field
  • Đổi type

✅ Thay vào đó:

  • Thêm field mới
  • Deprecate dần field cũ

3️⃣ Versioning API

Ví dụ:

/api/v1/users
/api/v2/users

Giúp client có thời gian migrate


4️⃣ Contract testing

  • Test để đảm bảo response không phá vỡ contract
  • Có thể dùng consumer-driven contract testing

5️⃣ Check tự động trong CI/CD

  • Detect breaking change trước khi deploy
  • Ngăn lỗi ngay từ pipeline

🎯 Khi nào bạn thực sự cần Data Contract?

  • Hệ thống có nhiều microservices
  • Có data pipeline (ETL, analytics, Kafka…)
  • Nhiều team cùng sử dụng chung API
  • Release thường xuyên (CI/CD)

👉 Nói ngắn gọn: hầu hết hệ thống hiện đại đều cần


🧩 Kết luận

Trong hệ thống đơn giản, thay đổi data có thể chỉ gây lỗi nhỏ.
Nhưng trong hệ thống lớn, nó có thể gây:

❗ Lỗi dây chuyền
❗ Sai dữ liệu
❗ Ảnh hưởng production diện rộng

Data Contract giúp chuyển từ:

❌ “Ai thích đổi gì thì đổi”

✅ “Mọi thay đổi đều có kiểm soát và an toàn”