Schema Registry và Tiến hóa Schema
1. Tổng quan
Schema Registry là một hệ thống quản lý metadata đăng ký và quản lý phiên bản tập trung cho cấu trúc dữ liệu (schema) của các luồng sự kiện và thông điệp, kiểm tra xem các thông điệp trao đổi giữa Producer và Consumer có tuân theo schema đã thống nhất hay không, và cưỡng chế sự tiến hóa an toàn theo quy tắc tương thích (compatibility) mỗi khi schema thay đổi.
Khi các kiến trúc hướng sự kiện (EDA) xây dựng trên Apache Kafka lan rộng, việc một topic được hàng chục dịch vụ đồng thời sản xuất và tiêu thụ đã trở nên phổ biến. Tuy nhiên, phần thân thông điệp chỉ là một mảng byte, nên khi Producer thêm một trường hoặc đổi kiểu, Consumer không hay biết sẽ thất bại khi giải tuần tự hóa (deserialization) hoặc âm thầm đọc ra giá trị sai. Hiện tượng các dịch vụ được triển khai ở những thời điểm khác nhau ngầm giả định cùng một cấu trúc dữ liệu rồi lệch nhau này được gọi là schema drift, và là nguyên nhân sự cố vận hành tiêu biểu trong hệ thống phân tán.
Cách làm truyền thống là Producer và Consumer mã hóa cứng schema và chia sẻ qua một thư viện chung. Nhưng điều này sinh ra hai vấn đề căn bản. Thứ nhất, mỗi lần đổi schema phải triển khai lại tất cả dịch vụ đồng thời, phá vỡ ghép lỏng (loose coupling) vốn là bản chất của EDA. Thứ hai, truyền toàn bộ schema cùng mỗi thông điệp làm phình to payload. Schema Registry giải quyết cả hai cùng lúc bằng cách cho phép schema được đăng ký một lần và tham chiếu qua một ID nguyên. Chỉ ID schema—khoảng 5 byte—đi kèm thông điệp, còn định nghĩa cấu trúc thực tế được tra cứu từ registry.
Giá trị cốt lõi của Schema Registry là tính độc lập về thứ tự triển khai. Nó cố định sẵn bằng giao ước những gì "có thể thay đổi" và những gì "không thể thay đổi" để tính tương thích của thông điệp không bị phá vỡ ngay cả khi Producer và Consumer được triển khai ở những thời điểm khác nhau mà không biết về nhau. Điều này vượt khỏi một bộ kiểm tra hợp lệ đơn thuần và đang tiến hóa thành một công cụ quản trị xem dữ liệu như một hợp đồng (contract).
Tóm lại, Schema Registry có bốn đặc trưng sau.
- Đăng ký và quản lý phiên bản tập trung: schema được đăng ký theo đơn vị subject và gán phiên bản cùng ID toàn cục.
- Cưỡng chế tương thích: kiểm tra chính sách tại thời điểm đăng ký để chặn trước các thay đổi gây vỡ.
- Hiệu quả tham chiếu: chỉ gắn ID schema lên thông điệp để tối thiểu hóa payload.
- Ghép lỏng: cho phép Producer và Consumer triển khai độc lập.
Mối quan tâm này về bản chất giống với việc đánh phiên bản API trong REST API đồng bộ. Trong REST, phiên bản được nêu rõ qua URI như /v1, /v2 và client chọn phiên bản mình muốn; nhưng trong luồng sự kiện bất đồng bộ, Consumer không thể "chọn" thông điệp mà phải nhận toàn bộ các thông điệp quá khứ và hiện tại chất trong topic, theo thứ tự. Do đó quản lý phiên bản trong thế giới sự kiện phải giải không bằng mô hình "client chọn" mà bằng bảo đảm tương thích "bất kỳ phiên bản nào cũng đọc được mà không vỡ", và đây đúng là vai trò Schema Registry đảm nhận. Nói cách khác, hiểu Schema Registry như một lớp quản lý hợp đồng API cho kiến trúc hướng sự kiện là chính xác.
2. Cấu trúc và Hoạt động của Schema Registry
Schema Registry là một dịch vụ tra cứu gồm Producer, Consumer, bộ tuần tự hóa/giải tuần tự hóa (SerDes) và kho lưu trữ. Trước khi gửi thông điệp, Producer đăng ký schema và nhận ID, gắn nó vào đầu thông điệp; Consumer tra ngược schema theo ID đó để diễn giải thông điệp an toàn. Sơ đồ cấu trúc dưới đây cho thấy mối quan hệ giữa tất cả các thành phần.
graph LR
subgraph P["Phía Producer"]
PA["Ứng dụng"] --> PS["Bộ tuần tự hóa(SerDes)"]
end
subgraph R["Schema Registry"]
API["REST API"] --> STORE["Kho schema(topic Kafka/DB)"]
API --> CHK["Bộ kiểm tra tương thích"]
end
subgraph C["Phía Consumer"]
CS["Bộ giải tuần tự hóa(SerDes)"] --> CA["Ứng dụng"]
end
PS -->|"đăng ký/tra cứu schema"| API
PS -->|"ID+payload"| BROKER["Message broker(Kafka)"]
BROKER -->|"ID+payload"| CS
CS -->|"tra schema theo ID"| API
Bộ tuần tự hóa (SerDes) là thư viện client giao tiếp với registry và là thành phần quan trọng nhất. Ở phía Producer, ngay trước khi gửi, bộ tuần tự hóa đăng ký schema của đối tượng với registry (hoặc xác nhận ID từ cache), gắn "magic byte + ID schema 4 byte" vào đầu thông điệp rồi mã hóa nhị phân phần thân. Phía Consumer tách ID ra và lấy schema từ registry (cache cục bộ một khi đã nhận) để giải tuần tự hóa. Nhờ đó chỉ ID schema đi lại trên mạng, và việc tra cứu registry chỉ xảy ra khi cache miss, nên gần như không ảnh hưởng đến thông lượng.
Kho schema lưu các schema đã đăng ký cùng phiên bản và metadata subject. Triển khai của Confluent dùng một topic nội bộ Kafka tên _schemas làm log thay vì một DB riêng, và các thực thể registry phát lại (replay) nó để khôi phục trạng thái đồng nhất. Nhờ vậy bản thân registry kế thừa trực tiếp khả năng nhân bản và bền vững của Kafka. Subject là không gian tên cho các phiên bản của một schema, thường có dạng <tên topic>-value, <tên topic>-key (TopicNameStrategy). Một subject chứa nhiều phiên bản như v1, v2, v3, và mỗi phiên bản được gán một ID duy nhất toàn cục.
Bộ kiểm tra tương thích so sánh schema mới với các phiên bản hiện có khi có yêu cầu đăng ký và từ chối nếu vi phạm chính sách tương thích đã cấu hình. Chẳng hạn khi Producer cố xóa một trường mà một Consumer đọc như bắt buộc, registry chặn ngay tại giai đoạn đăng ký, ngăn sự cố trước khi triển khai. "Cổng tại thời điểm đăng ký" này biến Schema Registry không phải một kho đơn thuần mà thành một điểm kiểm soát quản trị. Thực tế, các đường ống giao dịch thời gian thực trong tài chính đưa kiểm tra tương thích vào CI pipeline, làm thất bại PR thay đổi schema không tương thích ngay ở giai đoạn build (gọi là schema-as-code).
Nhìn cụ thể bố cục byte khi truyền sẽ cảm nhận được hiệu quả. Một thông điệp định dạng Confluent gồm "magic byte (0x00) 1 byte + ID schema 4 byte + payload thực tế". Nghĩa là thay vì gắn toàn bộ định nghĩa schema (một schema JSON/Avro có thể từ vài trăm byte đến vài KB) vào mỗi thông điệp, chỉ một tiền tố 5 byte nhận diện đó là cấu trúc nào. Trên một topic truyền hàng trăm nghìn sự kiện mỗi giây, khác biệt này tiết kiệm băng thông mạng và chi phí lưu trữ hàng chục lần. Consumer chỉ tra registry một lần với một ID lần đầu thấy và dùng cache cục bộ về sau, nên registry chỉ nằm trên mặt phẳng điều khiển (control plane), không nằm trên đường truyền lưu lượng. Thiết kế này là cốt lõi để đạt đồng thời "quản trị tập trung" và "thông lượng cao phân tán".
3. Tiến hóa Schema và Chính sách Tương thích
Câu hỏi cốt lõi của tiến hóa schema là "khi schema thay đổi, ai phải được triển khai trước mới an toàn". Chính sách tương thích quy định thứ tự triển khai này. Luồng trạng thái dưới đây cho thấy quá trình kiểm tra tương thích.
flowchart TD
A["Yêu cầu đăng ký schema mới"] --> B{"Kiểm tra chế độ tương thích"}
B -->|"NONE"| G["Bỏ kiểm tra và đăng ký"]
B -->|"BACKWARD"| C["Schema mới có đọc được dữ liệu phiên bản cũ?"]
B -->|"FORWARD"| D["Schema cũ có đọc được dữ liệu phiên bản mới?"]
B -->|"FULL"| E["Cả hai chiều đều được?"]
C -->|"được"| G
C -->|"không"| F["Từ chối đăng ký(409)"]
D -->|"được"| G
D -->|"không"| F
E -->|"được"| G
E -->|"không"| F
G --> H["Gán số phiên bản mới và ID toàn cục"]
Confluent Schema Registry cung cấp bảy chế độ tương thích (BACKWARD, BACKWARD_TRANSITIVE, FORWARD, FORWARD_TRANSITIVE, FULL, FULL_TRANSITIVE, NONE). Mặc định là BACKWARD. Khi gắn hậu tố _TRANSITIVE, đối tượng kiểm tra mở rộng từ "một phiên bản liền trước" thành "tất cả phiên bản đã đăng ký đến nay", nên dữ liệu ghi theo bất kỳ phiên bản quá khứ nào cũng được xử lý an toàn.
| Chế độ | Thay đổi được phép (tiêu biểu) | Cơ sở kiểm tra | Thứ tự nâng cấp |
|---|---|---|---|
| BACKWARD (mặc định) | xóa trường, thêm trường có giá trị mặc định | phiên bản liền trước | Consumer trước |
| BACKWARD_TRANSITIVE | như trên | tất cả phiên bản | Consumer trước |
| FORWARD | thêm trường, xóa trường có giá trị mặc định | phiên bản liền trước | Producer trước |
| FORWARD_TRANSITIVE | như trên | tất cả phiên bản | Producer trước |
| FULL | thêm/xóa trường có giá trị mặc định | phiên bản liền trước | thứ tự tùy ý |
| FULL_TRANSITIVE | như trên | tất cả phiên bản | thứ tự tùy ý |
| NONE | mọi thay đổi | không kiểm tra | không bảo đảm |
Tương thích ngược (BACKWARD) là quy tắc "schema mới phải đọc được dữ liệu cũ". Do đó nâng cấp Consumer lên phiên bản mới trước, rồi mới đến Producer. Các thay đổi xóa một trường hoặc thêm một trường có giá trị mặc định được phép. Lý do Confluent lấy đây làm mặc định là ngay cả khi tua topic về đầu (rewind) để tái xử lý, Consumer mới nhất vẫn đọc được mọi thông điệp quá khứ. Đây là lựa chọn an toàn nhất trong thực tế, nơi tái xử lý log và phục hồi sự cố diễn ra thường xuyên.
Tương thích xuôi (FORWARD) là quy tắc ngược lại: "schema cũ phải đọc được dữ liệu mới", và Producer được nâng cấp trước. Nó phù hợp tình huống mà Consumer còn ở phiên bản cũ phải đọc thông điệp do Producer phiên bản mới tạo mà không vỡ—ví dụ tích hợp B2B nơi đối tác bên ngoài kiểm soát Consumer và không thể nâng cấp ngay. Tương thích đầy đủ (FULL) yêu cầu cả hai chiều, giải phóng chính thứ tự triển khai, nhưng thu hẹp các thay đổi được phép thành "thêm và xóa các trường có giá trị mặc định". Nó được dùng để tối đa hóa an toàn trong các tổ chức lớn nơi kiểm soát khó nhất.
Một thay đổi gây vỡ không thể qua kiểm tra tương thích, tức breaking change, đôi khi không thể tránh. Khi đó, thay vì ép cùng một subject tiến hóa, ta tạo một topic mới (ví dụ orders.v2) để chạy song song luồng mới và cũ và di dời Consumer dần dần—mẫu ghi kép (dual-write) / mở rộng rồi thu hẹp (expand-and-contract). Producer ghi vào cả hai topic một thời gian, và sau khi tất cả Consumer đã chuyển sang topic mới thì topic cũ được loại bỏ. Schema Registry bảo đảm độc lập tính tương thích của từng topic ngay trong thời gian chuyển tiếp này, cho phép di dời quy mô lớn mà không gián đoạn.
Hàm ý thực tế rất rõ. Việc chọn chế độ tương thích không phải một sở thích kỹ thuật mà là một quyết định quản trị triển khai của tổ chức. Nếu một đội kiểm soát cả Producer lẫn Consumer thì BACKWARD là đủ; nhưng nếu Consumer rải rác khắp nhiều tổ chức và không thể kiểm soát, phải nâng lên FULL_TRANSITIVE để bảo đảm mạnh "không bao giờ vỡ". Trong khi đó NONE tắt kiểm tra nên bị cấm ngoài giai đoạn phát triển sớm; lạm dụng NONE trong môi trường vận hành biến registry thành "một kho phiên bản đắt tiền".
4. So sánh Định dạng Tuần tự hóa (Avro, Protobuf, JSON Schema)
Schema Registry không gắn với một định dạng tuần tự hóa cụ thể, nhưng mỗi định dạng xử lý tiến hóa schema khác nhau. Từ Confluent 5.5 cả ba định dạng đều được hỗ trợ, và quy tắc "thế nào là một thay đổi tương thích" khác nhau theo định dạng. Ví dụ ở chế độ FORWARD, Protobuf cấm thêm kiểu thông điệp mới—một trong nhiều ràng buộc theo định dạng.
| Khía cạnh | Apache Avro | Protobuf | JSON Schema |
|---|---|---|---|
| Mã hóa | nhị phân (schema tách riêng) | nhị phân (số tag) | văn bản (JSON) |
| Nhận diện tiến hóa | tên trường + giá trị mặc định | số trường | tên thuộc tính |
| Kích thước/tốc độ | nhỏ và nhanh | nhỏ và nhanh | lớn và chậm |
| Dễ đọc | thấp | thấp | cao |
| Lĩnh vực phù hợp | đường ống dữ liệu/phân tích | gRPC/RPC hiệu năng cao | thân thiện web/REST |
Avro truyền dữ liệu tách rời khỏi schema và, khi giải tuần tự hóa, dùng cả "schema ghi (writer)" lẫn "schema đọc (reader)" để ánh xạ các trường theo tên. Nhờ cấu trúc này, quy tắc tiến hóa schema của nó rõ ràng, và nó đã trở thành chuẩn de facto cho lưu trữ dữ liệu lớn (Hadoop/data lake). Tuy nhiên, thiết kế giá trị mặc định (default) là trái tim của sự tiến hóa, nên bỏ sót giá trị mặc định ở một trường được thêm sẽ phá vỡ tương thích ngược.
Ví dụ, giả sử bạn thêm một trường tùy chọn coupon_code vào một sự kiện đơn hàng trong Avro. Để giữ tương thích ngược (BACKWARD), bạn phải chỉ định giá trị mặc định cho trường này (ví dụ "default": ""). Chỉ khi đó một Consumer phiên bản mới mới điền giá trị mặc định khi đọc một thông điệp quá khứ thiếu trường và giải tuần tự hóa thành công. Nếu bỏ sót giá trị mặc định, registry từ chối chính việc đăng ký (HTTP 409), phơi bày lỗi thiết kế trước khi nó tới môi trường vận hành. Như vậy "thiết kế giá trị mặc định" là điểm sai sót phổ biến nhất của tiến hóa Avro và là cơ chế cốt lõi của tương thích.
Protobuf nhận diện các trường không bằng tên mà bằng số tag nguyên. Do đó chỉ cần giữ số thì đổi tên vẫn tương thích, và kết hợp với gRPC nó mạnh ở giao tiếp giữa các dịch vụ độ trễ thấp. Tuy nhiên tái sử dụng một số tag đã dùng sẽ âm thầm làm hỏng dữ liệu, nên kỷ luật niêm phong vĩnh viễn số đã xóa bằng reserved là bắt buộc. JSON Schema dựa trên văn bản nên dễ đọc với con người và thân thiện với hệ sinh thái web, nhưng payload lớn và phân tích cú pháp chậm, khiến nó không phù hợp cho streaming thông lượng siêu cao. Trong thực tế, phổ biến là trộn theo lĩnh vực—"Avro cho đường ống phân tích lớn, Protobuf cho RPC giữa các microservice nội bộ, JSON Schema cho các sự kiện API công bố ra ngoài".
5. So sánh các Triển khai
Các triển khai tiêu biểu gồm Confluent Schema Registry (chuẩn de facto trong hệ sinh thái Kafka), AWS Glue Schema Registry (được quản lý, tích hợp với Kinesis/MSK), và Apicurio Registry mã nguồn mở (hỗ trợ rộng Avro, Protobuf, JSON Schema, và cả OpenAPI/AsyncAPI). Confluent tích hợp sâu với Kafka trên một topic _schemas và có độ trưởng thành vận hành cao; Glue không máy chủ (serverless) với gánh nặng vận hành ít và kết hợp tự nhiên với IAM. Apicurio phù hợp các tổ chức tránh khóa nhà cung cấp hoặc muốn quản lý cả đặc tả API cùng nhau.
Lấy ví dụ về quy mô, các tổ chức tầm Netflix/LinkedIn xử lý hàng nghìn tỷ sự kiện mỗi ngày và vận hành hàng nghìn subject. Ở quy mô này, không có cache ID schema, nhân bản registry, và một quy trình phê duyệt xem thay đổi schema như duyệt mã, thì một thay đổi trường nhỏ nhặt có thể làm đình trệ đường ống toàn doanh nghiệp. Thực tế, một trường hợp fintech báo cáo rằng sau khi tích hợp kiểm tra tương thích vào CI cho các schema sự kiện thanh toán, sự cố vận hành liên quan đến schema giảm từ vài vụ mỗi quý xuống gần bằng không (hiểu như một xu hướng chung).
Tóm tắt tiêu chí lựa chọn như sau. Ba triển khai chia sẻ bản chất một mô hình tương thích nhưng khác nhau ở nơi đặt trách nhiệm vận hành và phạm vi hỗ trợ.
| Khía cạnh | Confluent | AWS Glue | Apicurio |
|---|---|---|---|
| Cách lưu trữ | topic Kafka _schemas |
được quản lý (serverless) | tùy chọn SQL DB/Kafka, v.v. |
| Gánh nặng vận hành | tự vận hành (self-hosted) | gần như không (quản lý trọn gói) | tự vận hành |
| Đặc tả hỗ trợ | Avro, Protobuf, JSON Schema | Avro, Protobuf, JSON | như trên + OpenAPI, AsyncAPI |
| Tình huống phù hợp | lấy Kafka làm trung tâm, trưởng thành cao | gắn với AWS, đơn giản hóa vận hành | đa đặc tả, trung lập nhà cung cấp |
Chiến lược đặt tên subject cũng là một quyết định thiết kế quan trọng trong thực tế. TopicNameStrategy mặc định (<topic>-value) đơn giản khi một topic chỉ chứa một loại sự kiện, nhưng khi một topic phải trộn nhiều kiểu sự kiện trong khi vẫn bảo toàn thứ tự, bạn phải chuyển sang RecordNameStrategy (theo tên kiểu bản ghi) hoặc TopicRecordNameStrategy (topic + tên bản ghi). Chọn sai chiến lược khiến các sự kiện khác nhau chia sẻ cùng một subject và làm kiểm tra tương thích hoạt động sai lệch, nên phải quyết định sớm trong thiết kế topic.
6. Chuyên sâu: Tiến hóa thành Hợp đồng Dữ liệu (Data Contract)
Gần đây Schema Registry được đánh giá lại như một công nghệ trung tâm trong cuộc thảo luận về Hợp đồng Dữ liệu (Data Contract) và Data Mesh. Hợp đồng dữ liệu là "một cam kết tường minh, được quản lý phiên bản giữa đội sản xuất dữ liệu và đội tiêu thụ nó", bao gồm không chỉ schema (cấu trúc) mà cả ngữ nghĩa (semantics), kỳ vọng chất lượng (SLO), và quyền sở hữu. Schema Registry đảm nhận phần cấu trúc máy có thể cưỡng chế của hợp đồng này. Trong một data mesh, khi mỗi miền công bố dữ liệu như một "sản phẩm dữ liệu (data product)", chính sách tương thích chính là mức ổn định API của sản phẩm.
Một dấu hiệu trưởng thành khác là tham chiếu schema (schema references). Các kiểu chung (ví dụ Address, Money) được định nghĩa thành các schema riêng, và nhiều schema sự kiện tham chiếu chúng, tái sử dụng và chuẩn hóa định nghĩa dữ liệu trên toàn tổ chức. Điều này tương đương quản lý "shared kernel" giữa các microservice một cách khai báo trong registry thay vì trong một thư viện mã, giảm sự không nhất quán ngữ nghĩa do định nghĩa trùng lặp. Tuy nhiên, khi tham chiếu sâu thêm, bán kính ảnh hưởng của một thay đổi mở rộng, nên các schema chung cần quản trị phân tầng áp dụng chính sách tương thích nghiêm ngặt hơn (FULL_TRANSITIVE) và một quy trình phê duyệt thay đổi.
Confluent đáp lại điều này bằng cách mở rộng theo hướng các tính năng Data Contracts kết hợp metadata/tag trên một schema (ví dụ đánh dấu PII), kiểm tra/biến đổi dựa trên quy tắc (rule), và quy tắc di trú. Ví dụ, đánh dấu một trường thông tin cá nhân (PII) bằng một tag schema có thể được nối để các đường ống hạ nguồn tự động áp dụng quy tắc che/mã hóa. Điều này cho thấy Schema Registry đang được nâng từ một công cụ hỗ trợ tuần tự hóa đơn thuần thành một điểm thực thi cho quản trị dữ liệu và bảo vệ thông tin cá nhân. Về sau, Schema Registry được kỳ vọng tích hợp với các hệ thống data catalog/lineage (phả hệ) để tự động phân tích (impact analysis) ảnh hưởng hạ nguồn của một thay đổi schema.
7. Cân nhắc và Hàm ý
- Chính sách tương thích là một vấn đề thiết kế tổ chức. Dưới góc nhìn Kỹ sư chuyên nghiệp, lựa chọn giữa BACKWARD/FORWARD/FULL phải suy ra không từ hiệu năng mà từ cấu trúc tổ chức "ai kiểm soát Producer và Consumer". Một đội nội bộ duy nhất mặc định BACKWARD; tích hợp đa tổ chức/bên ngoài mặc định FULL_TRANSITIVE, và một thiết kế phân biệt chính sách theo từng subject là điều nên làm.
- Quản lý schema như mã (schema-as-code). Các thay đổi schema nên được xử lý bằng Git PR và kiểm tra tương thích trong CI để chặn vỡ trước khi triển khai. Khoảnh khắc chế độ NONE được cho phép trong vận hành, giá trị quản trị của registry biến mất, nên NONE nên bị cấm theo chính sách tổ chức và các ngoại lệ đặt dưới một quy trình phê duyệt.
- Làm rõ các đánh đổi của lựa chọn định dạng. Avro (phân tích/đường ống), Protobuf (RPC độ trễ thấp), và JSON Schema (API công bố ra ngoài) mỗi loại có quy tắc tiến hóa và đặc tính hiệu năng khác nhau. Các cạm bẫy theo định dạng—cấm tái sử dụng số tag của Protobuf, thiết kế giá trị mặc định của Avro—phải được ghi thành hướng dẫn mới phòng được sự cố vận hành.
- Điểm hỏng đơn (SPOF) và tính sẵn sàng. Vì bộ tuần tự hóa phụ thuộc vào registry, một sự cố registry có thể làm đình trệ toàn bộ sản xuất và tiêu thụ. Hãy thiết kế nhân bản, cache schema cục bộ, và một dự phòng chỉ đọc, và khớp SLO sẵn sàng của registry với mức của message broker.
- Triển vọng liên kết quản trị và thông tin cá nhân. Nhận diện PII dựa trên tag schema, hợp đồng dữ liệu, và tích hợp lineage/catalog mở rộng Schema Registry thành một điểm thực thi cho quản trị dữ liệu. Về sau, trong môi trường data mesh nó sẽ giữ vị trí như một trục cốt lõi tự động hóa việc kiểm soát chất lượng, tương thích và thông tin cá nhân của sản phẩm dữ liệu từng miền.
Tài liệu tham khảo
- Confluent, "Schema Evolution and Compatibility", https://docs.confluent.io/platform/current/schema-registry/fundamentals/schema-evolution.html
- Confluent, "Schema Registry API Reference", https://docs.confluent.io/platform/current/schema-registry/develop/api.html
- AWS, "AWS Glue Schema Registry", https://docs.aws.amazon.com/glue/latest/dg/schema-registry.html
- Apicurio Registry, https://www.apicur.io/registry/
Tóm tắt một câu: Schema Registry quản lý phiên bản tập trung cho cấu trúc dữ liệu của các luồng sự kiện và cưỡng chế tiến hóa schema an toàn thông qua các chính sách tương thích (BACKWARD, FORWARD, FULL), ghép lỏng Producer và Consumer và tiến hóa thành một điểm thực thi cho hợp đồng dữ liệu và quản trị.