Petunjuk dan ruang lingkup
Pertanyaan ini menguji apakah seorang data engineer dapat mengubah kesepakatan data antartim menjadi antarmuka yang dapat diverifikasi dan dikembangkan. Asumsikan tim pembayaran memublikasikan event pesanan yang digunakan oleh dasbor keuangan, fitur risiko, dan laporan operasi; tipe field, makna bisnis, ambang batas kualitas, dan jendela ketersediaan belum disepakati, sehingga perubahan kecil dapat memicu insiden di downstream.
Topik ini cocok untuk data engineer, data platform engineer, dan peran tata kelola produk data. Fokuslah pada batasan kontrak, kepemilikan, kompatibilitas versi, validasi, dan penanganan kegagalan daripada pilihan Kafka, data warehouse, atau vendor tertentu. Nyatakan apa yang dijamin oleh produsen, apa yang boleh diasumsikan oleh konsumen, dan bagaimana cara memblokir atau melakukan degradasi layanan saat jaminan tidak dapat dipenuhi.
Hal yang dinilai oleh pewawancara
Jawaban yang kuat memisahkan kontrak data dari sekadar skema: kontrak juga menjelaskan semantik field, asersi kualitas, data sensitif, tingkat layanan, kepemilikan, dan aturan perubahan. Jawaban tersebut menurunkan kontrak minimum dari kebutuhan konsumen, menjelaskan batasan antara pemeriksaan pra-rilis dan pemantauan runtime, serta menggunakan kebijakan kompatibilitas untuk penambahan, penghentian (deprecation), dan perubahan semantik. Jawaban juga menyebutkan pemilik notifikasi, batas isolasi, jalur rollback, dan strategi pemutaran ulang (replay) saat terjadi pelanggaran kontrak.
Pertanyaan klarifikasi yang perlu diajukan
- Apakah aset tersebut berupa event stream, tabel, file, atau fitur model? Berapa tingkat kebaruan dan latensi yang diizinkan?
- Konsumen mana saja yang bergantung padanya, serta field, semantik waktu, presisi, dan retensi apa yang mereka butuhkan?
- Apa arti "benar" di sini: keharusan diisi (requiredness), keunikan, rentang, enum, aturan lintas field, dan rekonsiliasi?
- Field mana saja yang berisi data pribadi atau keuangan, dan siapa yang menyetujui akses, penyamaran (masking), serta penggunaan yang diizinkan?
- Apakah perubahan ini kompatibel ke belakang (backward compatible), apakah memerlukan penulisan ganda (dual writes), atau haruskah release gate menolaknya? Bisakah pelanggaran ditunda, diisolasi, atau di-rollback?
Kerangka jawaban 30 detik
"Saya akan meminta konsumen menyatakan kebutuhan bisnis mereka terlebih dahulu, kemudian membagi kontrak menjadi struktur, semantik, kualitas, kebaruan, keamanan, dan tanggung jawab. Setiap kontrak memiliki pemilik, versi, status, dan kebijakan perubahan. Produsen menjalankan pemeriksaan skema dan kualitas sebelum rilis; konsumen memantau kebaruan dan ketersediaan saat penyerapan data (ingestion). Perubahan yang kompatibel dapat langsung dirilis, sementara perubahan yang merusak (breaking changes) menggunakan versi baru, migrasi jalur ganda, dan jendela depresiasi. Pemeriksaan yang gagal akan mengisolasi data yang buruk, memberi tahu pemilik, dan menyimpan input mentah yang dapat diputar ulang. Saya akan memvalidasi rancangan ini dengan tingkat cacat perubahan (change-defect rate), lokasi pertama kali pelanggaran terdeteksi, dan waktu pemulihan."
Jawaban langkah demi langkah
Langkah 1: Batasi kontrak berdasarkan use case konsumen
Buat daftar field dan keputusan yang benar-benar dibutuhkan konsumen daripada menyalin setiap kolom dari tabel produsen. Untuk setiap field, catat makna bisnis, satuan, zona waktu, nullability, dan sumber; misalnya, apakah total_amount berupa sen atau dolar dan apakah created_at merupakan waktu event atau waktu penulisan. Jaga agar detail implementasi internal tetap berada di luar janji yang dibagikan.
Langkah 2: Definisikan struktur, semantik, dan asersi kualitas
Struktur mencakup nama field, tipe, keharusan diisi, dan penumpukan (nesting). Semantik mencakup enum, satuan, jendela waktu, dan definisi kalkulasi. Asersi kualitas mencakup nilai null, keunikan, rentang, distribusi, dan hubungan lintas field. OpenMetadata memisahkan skema, semantik, keamanan, asersi bisnis, SLA, dan status; pemisahan berlapis ini mencegah kesalahpahaman bahwa "field itu ada" sama artinya dengan "data tersebut dapat dipercaya."
Langkah 3: Perjelas kebaruan, keamanan, dan kepemilikan
Definisikan frekuensi penyegaran, latensi maksimum, retensi, dan jendela ketersediaan. Tentukan pemilik dari pihak produsen, kontak cadangan, dan saluran dukungan konsumen. Tambahkan label klasifikasi, kebijakan akses, dan batasan penggunaan yang diizinkan untuk field sensitif. Batasan ini harus dapat ditegakkan: produsen menjamin kepatuhan terhadap kontrak, sementara konsumen tetap memvalidasi derivasi bisnis mereka sendiri.
Langkah 4: Pilih aturan penerapan versi dan kompatibilitas
Pisahkan versi kontrak dari versi implementasi produk data. Menambahkan field opsional biasanya kompatibel; menghapus field, mengubah tipenya, memperkecil enum, atau mengubah semantik waktu memiliki risiko tinggi. Publikasikan versi baru atau lapisan penerjemah untuk breaking changes, lakukan dual-write saat konsumen bermigrasi, tetapkan tenggat waktu, dan hentikan versi lama hanya setelah penggunaan dan jendela depresiasi mencapai nol. Mode kompatibilitas schema registry tidak dapat menyembunyikan perubahan semantik.
Langkah 5: Tempatkan kontrak di dalam release gate
Simpan kontrak dalam sistem kendali versi (version control) dan tinjau melalui pull request. CI harus memvalidasi format kontrak, kemudian menjalankan pemeriksaan struktur, kualitas, dan kompatibilitas terhadap data sampel atau data bayangan (shadow data) sebelum dipublikasikan. Kontrak data Confluent dapat mengekspresikan batasan integritas, metadata, aturan migrasi, dan tag data sensitif, yang menggambarkan mengapa aturan yang dapat dieksekusi jauh lebih kuat daripada pengingat dokumentasi. Gate yang gagal akan memblokir rilis atau mengarahkan data yang buruk ke karantina.
Langkah 6: Rancang perlindungan runtime dan pemulihan
Pantau kebaruan, ketiadaan data (missingness), pergeseran enum, latensi, kesalahan konsumen, dan status kontrak setelah rilis. Simpan payload mentah, versi, dan hasil validasi untuk pemutaran ulang. Dasbor atau layanan fitur dapat menggunakan snapshot tepercaya terakhir untuk sementara waktu dengan label basi (staleness); penyelesaian transaksi (settlement), otorisasi, dan tindakan lain yang tidak dapat dibatalkan harus berhenti dan mengirimkan peringatan. Peringatan harus mengarah ke pemilik dan jalur eskalasi, bukan hanya menyatakan "masalah data."
Langkah 7: Uji rancangan dengan satu skenario perubahan
Misalkan sebuah event pesanan mengubah amount dari bilangan bulat sen menjadi objek yang berisi jumlah dan mata uang. Identifikasi konsumen, publikasikan versi baru, lakukan dual-write, putar ulang sampel, dan rekonsiliasi hasil lama dan baru sebelum mendepresiasi versi lama. Jika refunded berubah dari "pengembalian dana dimulai" menjadi "pengembalian dana selesai", ini merupakan perubahan semantik yang merusak meskipun tipenya tidak berubah. Latihan ini membuktikan bahwa kontrak mencakup makna, bukan hanya bentuk field.
Langkah 8: Tinjau apakah kontrak berfungsi
Lacak proporsi breaking changes yang diblokir oleh gate, lokasi pertama kali insiden terdeteksi, waktu dari pelanggaran hingga pemulihan, sisa konsumen yang masih menggunakan versi lama, dan dataset yang tidak memiliki pemilik. Jika insiden masih pertama kali muncul di dasbor downstream, berarti pemeriksaan terlambat dilakukan atau asersi terlalu lemah. Jika kontrak berisi banyak field yang tidak digunakan, persempit batasannya. Berikan versi dan rawat kontrak seiring perubahan penggunaan bisnis dan konsumen; ini bukanlah dokumen yang dibuat satu kali saja.
Pertimbangan desain (trade-offs) dan batasan
Detail yang lebih banyak dapat memberikan perlindungan yang lebih kuat, tetapi juga meningkatkan biaya perubahan bagi produsen dan konsumen. Saya akan memasukkan asumsi antartim yang memengaruhi keputusan bisnis atau tidak dapat diputar ulang ke dalam kontrak wajib, sambil mempertahankan field eksperimental sebagai opsional. Tetapkan ambang batas kualitas berdasarkan use case: data settlement mungkin memerlukan kelengkapan yang ketat, sedangkan analisis eksploratif dapat mentoleransi penundaan dengan label keyakinan atau kebaruan yang eksplisit. Jangan menduplikasi setiap aturan tata kelola dalam satu file; tautkan persetujuan akses, persyaratan retensi, dan dokumentasi produk data untuk menghindari sumber kebenaran (source of truth) yang berjalan paralel.
Kapan rilis harus ditolak?
Saya akan menolak untuk menandai suatu versi sebagai aktif apabila makna field tidak jelas, pemilik kritis tidak ada, breaking change tidak memiliki rencana migrasi, atau asersi kualitas tidak dapat dijalankan di batasan mana pun. Versi tersebut dapat tetap berstatus draf sementara konsumen mengonfirmasi asumsi dan produsen menyediakan sampel serta bukti pemutaran ulang.
Bagaimana Anda menyelesaikan konflik antarkonsumen?
Pisahkan jaminan bersama dari kebutuhan khusus masing-masing konsumen. Jaga agar kontrak bersama tetap kecil, stabil, dan dapat diverifikasi. Jika satu konsumen membutuhkan presisi yang lebih tinggi atau latensi yang lebih rendah, sediakan produk data turunan atau SLA bertingkat daripada memaksa setiap konsumen membayar biaya yang sama. Setiap pengecualian harus memiliki pemilik, tanggal kedaluwarsa, dan kondisi keluar.
Rencana peluncuran dan bukti keberhasilan
Mulailah dengan dataset berdampak tinggi yang memiliki sekumpulan konsumen terbatas: daftarkan konsumen, tulis kontrak minimum, jalankan pemeriksaan sampel di CI, lalu tambahkan pemantauan kebaruan dan kualitas di batas produksi. Setelah migrasi pertama, tinjau perubahan yang diblokir, positif palsu (false positives), waktu pemulihan, dan umpan balik konsumen sebelum memperluas ke lebih banyak topik atau tabel. Bukti ini berguna untuk menyesuaikan asersi sebelum platform tata kelola besar dipasang tanpa pengguna.
Apa saja kriteria keluar (exit criteria) untuk uji coba?
Definisikan kriteria keluar: beberapa siklus rilis berhasil melewati gate, pelanggaran ditemukan sebelum mencemari downstream, konsumen menyelesaikan migrasi, dan pemilik merespons dalam jendela waktu yang disepakati. Jika kriteria tidak terpenuhi, persempit cakupan atau revisi kontrak daripada menampilkan uji coba yang gagal sebagai keberhasilan platform.
Bagaimana Anda membuktikan bahwa manfaatnya nyata?
Bandingkan breaking changes sebelum dan sesudah uji coba, lokasi deteksi pertama, jumlah rollback, dan waktu pemulihan, yang disegmentasikan berdasarkan dataset dan konsumen. Jika jumlah insiden turun sementara frekuensi rilis juga turun, sertakan throughput perubahan dan waktu tunggu. Jika gate memblokir banyak perubahan tetapi positif palsu tinggi, tingkatkan asersi dan sampel daripada menonaktifkan gate.
Kesalahan umum dan pertanyaan lanjutan
Menyebut tipe field sebagai kontrak data
Tipe dan keharusan diisi hanya melindungi bentuk data, bukan mata uang, semantik waktu, kualitas, kebaruan, akses, atau kepemilikan. Tanpa jaminan tersebut, konsumen dapat menerima data yang secara struktural valid tetapi secara semantik salah.
Membiarkan konsumen menanggung setiap perselisihan
Konsumen dapat memantau hasil kerja mereka sendiri, tetapi mereka tidak dapat memiliki definisi bersama produsen dan tanggung jawab rilis. Kontrak harus menyatakan jaminan produsen, asumsi konsumen, dan jalur eskalasi di antara keduanya.
Hanya memberikan peringatan saat runtime
Pada saat data yang buruk mencapai lapisan bersama, beberapa sistem downstream mungkin sudah terkontaminasi. Geser pemeriksaan struktur dan kompatibilitas ke tahap awal (shift left); gunakan pemantauan runtime dan karantina untuk asersi bisnis yang tidak dapat diputuskan sebelum rilis.
Bagaimana Anda mengklasifikasikan dan memigrasikan breaking change?
Nilai dampaknya terhadap konsumen, bukan hanya perbedaan skema (schema diff). Menghapus field, mengubah tipe, mempersempit enum, atau mengubah satuan maupun definisi waktu dapat merusak sistem konsumen. Publikasikan versi baru atau lapisan penerjemah, validasi kedua jalur, beri tahu pemilik, dan hapus versi lama hanya setelah penggunaan mencapai nol dan jendela depresiasi telah berlalu.
Pemeriksaan gagal tetapi bisnis harus tetap berjalan. Apa yang Anda lakukan?
Pisahkan tampilan yang bersifat reversibel dari tindakan yang tidak dapat diubah (irreversible). Jalur tampilan dapat menggunakan snapshot tepercaya terakhir dengan label basi yang eksplisit. Keputusan settlement, otorisasi, dan risiko harus mengarantina data yang buruk, menjeda tindakan yang terpengaruh, dan mempertahankan input mentah. Putar ulang, rekonsiliasi, dan dapatkan persetujuan konsumen sebelum mencabut karantina.
Bagaimana cara mencegah kontrak menjadi dokumen yang terbengkalai?
Sematkan kontrak ke dalam code review, CI gate, metadata katalog, dan status runtime. Hubungkan setiap kontrak dengan pemilik, kontak cadangan, daftar konsumen, dan waktu validasi terakhir. Tinjau tingkat pelanggaran, lokasi deteksi, dan waktu pemulihan, serta hentikan entri yang tidak memiliki konsumen atau tidak dapat ditegakkan.