# Breaking Schema Change pada Data Berskala Populasi

> Perubahan skema pada sistem data berskala besar tanpa strategi migrasi yang jelas menciptakan cascade failure di seluruh pipeline downstream.

**URL:** https://www.ciptadusa.com/blog/breaking-schema-change-data-governance-20260809  
**Type:** blog  
**Author:** PT Cipta Dua Saudara  
**Category:** Teknologi  
**Published:** 2026-08-09  
**Cover:** https://cdn-uagents.enitip.com/uploads/blog/2026-08/daily-engineering-20260809-014705.jpg  

## Article

Sebuah proposal baru untuk mengubah sensus nasional AS baru saja mengungkap masalah yang jarang dibicarakan di dunia engineering: apa yang terjadi ketika sebuah sistem data berskala populasi tiba-tiba menghapus field yang sudah dikonsumsi ribuan downstream service selama puluhan tahun?

## Ringkasan

Perubahan skema pada sistem data berskala besar tanpa strategi migrasi yang jelas menciptakan cascade failure di seluruh pipeline yang bergantung pada field yang dihapus — dari ML feature store hingga public API.

## Latar Belakang

Sensus AS sedang mempertimbangkan penghapusan beberapa field demografis — ras, orientasi seksual, dan status imigrasi — dari formulir pengumpulan data mereka. Dari perspektif kebijakan, ini kontroversial. Namun dari perspektif *data engineering*, ini adalah contoh nyata dari **breaking schema change** pada skala yang hampir mustahil untuk di-rollback.

Sistem sensus AS bukan sekadar survei. Data ini mengalir ke ribuan sistem downstream: alokasi dana federal, redistricting algorithm, model prediksi kesehatan publik, hingga training data untuk model ML yang digunakan perusahaan swasta. Setiap field yang dihapus adalah sebuah **contract violation** terhadap consumer yang sudah bergantung padanya.

## Pendekatan

Bagaimana seharusnya sebuah organisasi engineering menangani breaking schema change pada sistem berskala ini?

**1. Schema Registry dengan Versioning Eksplisit.** Apache Schema Registry atau solusi serupa memungkinkan producer mendeklarasikan versi skema baru tanpa langsung memutus consumer lama. Consumer yang belum siap tetap membaca v1 sementara yang sudah migrasi beralih ke v2.

**2. Deprecation Window dengan Data Lineage Tracking.** Sebelum menghapus field, identifikasi SEMUA downstream consumer melalui data lineage graph. Tools seperti **Apache Atlas**, **DataHub**, atau **OpenLineage** memetakan siapa yang membaca field apa. Tanpa ini, penghapusan field adalah tembakan buta.

**3. Tombstone Pattern untuk Field yang Dihapus.** Alih-alih menghapus field secara fisik, isi dengan sentinel value dan tambahkan metadata `deprecated_since`. Consumer yang belum migrasi mendapat warning di log mereka, bukan null pointer exception di production.

**4. Feature Store Isolation.** ML feature store yang mengkonsumsi data demografis harus memiliki abstraction layer yang menangani field absence gracefully — return default value atau fallback ke proxy feature, bukan crash pada missing column.

Ini bukan masalah teknis yang baru. Setiap organisasi yang menjalankan data platform pada skala tertentu pernah menghadapinya. Yang membuat kasus sensus menarik adalah skalanya: miliaran record, ribuan consumer, dan zero tolerance untuk downtime.

## Referensi

- [Census Proposal Would Stop Counting Undocumented Immigrants — Wired](https://www.wired.com/story/census-proposal-would-stop-counting-undocumented-immigrants-and-ignore-race-and-sexual-orientation/)
- [Schema Evolution and Compatibility — Confluent Documentation](https://docs.confluent.io/platform/current/schema-registry/fundamentals/schema-evolution.html)
- [OpenLineage Project — Data Lineage Standard](https://openlineage.io/)

---

*Markdown version of https://www.ciptadusa.com/blog/breaking-schema-change-data-governance-20260809 — generated for AI agents and LLM crawlers.*