Petunjuk dan ruang lingkup
Perlakukan ini sebagai pertanyaan desain data-engineering. Asumsikan terdapat 2.000 event pesanan per detik pada jam sibuk, target kesegaran (freshness) 15 menit, dan target kelengkapan 99,5% untuk kolom-kolom wajib. Kontrak harus mencakup struktur, makna, kualitas, tingkat layanan, kepemilikan, label privasi, dan proses untuk mengubah komitmen apa pun.
Batasan yang berguna adalah produk data antara produsen upstream dan konsumen downstream. Definisi tabel basis data saja terlalu sempit: definisi tersebut tidak dapat menyatakan apakah total_amount mencakup pajak, siapa pemilik feed tersebut, atau apa yang terjadi ketika target kesegaran data terlewat.
Apa yang sedang diuji oleh pewawancara
Pewawancara ingin mendengar tentang kontrak yang dapat dieksekusi, memiliki versi, dan dimiliki secara jelas. Jawaban yang lemah hanya menyebutkan Avro atau JSON Schema. Jawaban yang kuat memisahkan kompatibilitas dari kebenaran semantik, menempatkan pemeriksaan pada batas produsen, dan memberi konsumen jalur mitigasi pelanggaran serta migrasi yang dapat diprediksi.
Anda harus menghubungkan setiap kolom dengan keputusan konsumen: tolak, karantina, transformasi, beri peringatan, atau lanjutkan dengan status degradasi yang eksplisit. Anda juga harus menjelaskan bagaimana kontrak menghindari berubah menjadi antrean persetujuan tanpa dokumentasi.
Klarifikasi yang mengubah desain
- Apakah sumbernya berupa aliran event append-only, tabel yang dapat diubah (mutable), atau keduanya? Snapshot yang dapat diubah memerlukan kunci, semantik pembaruan, dan aturan penghapusan.
- Jaminan mana yang merupakan batasan mutlak (hard launch gates)? Event pembayaran mungkin ditolak jika mata uang tidak valid, sedangkan label pemasaran opsional dapat dikarantina.
- Bisakah konsumen tertinggal satu versi? Jika ya, publikasikan jendela kompatibilitas dan transformasi; jika tidak, wajibkan cutover yang terkoordinasi.
- Apakah event dapat diputar ulang (replayable) dan apakah mengandung data pribadi? Kemampuan putar ulang memengaruhi retensi, dan label privasi memengaruhi masking, akses, serta penanganan penghapusan.
Kerangka jawaban 30 detik
"Saya akan mulai dari kasus penggunaan konsumen dan menulis kontrak berversi yang dapat dibaca mesin. Kontrak tersebut akan mendefinisikan skema dan semantik, pemeriksaan kolom wajib dan domain, SLO kesegaran dan kelengkapan, kepemilikan, label privasi, serta kebijakan evolusi. Produsen memvalidasi sebelum memublikasikan; registri memeriksa kompatibilitas di CI; pemeriksaan runtime mengarantina rekaman yang buruk dan mengekspos metrik. Versi baru bersifat aditif secara default, dengan jendela publikasi ganda (dual-publish) atau transformasi untuk perubahan semantik yang merusak (breaking changes). Setiap pelanggaran memiliki pemilik, jalur pemutaran ulang, dan status yang terlihat oleh konsumen."
Desain langkah demi langkah
1. Definisikan objek kontrak
Beri dataset sebuah pengidentifikasi dan versi. Untuk setiap kolom, catat tipe data, nullability, unit, makna bisnis, nilai yang diizinkan, sensitivitas, dan apakah kolom yang tidak dikenal diizinkan. Untuk event pesanan, nyatakan apakah occurred_at merupakan waktu event, apakah jumlah merupakan unit minor integer, dan apakah pesanan yang dibatalkan tetap terlihat.
Tambahkan kepemilikan, kontak dukungan, retensi, kesegaran, frekuensi pengiriman, dan ketersediaan. Tingkat layanan harus dapat diukur: kesegaran bisa berupa usia rekaman terbaru yang diterima, sedangkan kelengkapan bisa berupa rasio kolom wajib yang tidak bernilai null selama suatu periode jendela.
2. Pisahkan pemeriksaan berdasarkan mode kegagalan
Pemeriksaan skema menangkap kolom yang hilang dan tipe data yang tidak kompatibel. Pemeriksaan domain menangkap jumlah di bawah nol atau mata uang yang tidak didukung. Pemeriksaan relasional menangkap ID event duplikat atau transisi pesanan yang melewati status yang diperlukan. Pemeriksaan kesegaran dan volume menangkap produsen yang macet atau partisi parsial.
Simpan hasil pengujian beserta versi kontrak, build produsen, partisi, jendela sampel, dan aturan yang gagal. Bukti tersebut memungkinkan konsumen memutuskan apakah akan menjeda, melakukan backfill, atau menerima degradasi yang terbatas.
3. Terapkan penegakan sebelum dan sesudah publikasi
Di CI, bandingkan skema yang diajukan dengan versi terdaftar dan jalankan pengujian kontrak yang representatif. Saat runtime, validasi pada batas produsen sebelum event masuk ke aliran bersama. Kirim rekaman yang tidak valid ke aliran karantina beserta payload asli, aturan yang gagal, versi kontrak, dan kunci pemutaran ulang.
Konsumen harus tetap memvalidasi invarian kritis pada batas mereka sendiri. Penegakan di sisi produsen mencegah banyak insiden; pemeriksaan konsumen melindungi dari rute yang salah konfigurasi, produsen lama, dan bug transformasi.
4. Buat evolusi menjadi eksplisit
Perlakukan penambahan kolom opsional sebagai perubahan yang menjaga kompatibilitas hanya jika konsumen lama menoleransi kolom yang tidak dikenal. Pengubahan nama bersifat merusak (breaking) karena makna atau nama kolom berubah. Lebih disukai pendekatan tambah-lalu-usangkan (add-and-deprecate): publikasikan kolom baru, lakukan penulisan ganda (dual-write) atau transformasi, migrasikan konsumen, ukur pembacaan pada kolom lama, lalu hentikan penggunaan kolom tersebut setelah jendela waktu yang ditentukan.
Untuk perubahan semantik seperti mengubah total_amount dari termasuk pajak menjadi belum termasuk pajak, versi baru dan kolom baru lebih aman daripada menggunakan kembali nama yang sama. Jika konsumen harus tetap menggunakan tampilan lama, gunakan transformasi berversi dan beri label pada nilai yang dikonversi.
5. Tentukan penanganan pelanggaran
Gunakan tingkat keparahan. Event pembayaran yang salah format akan ditolak dan dikarantina. Pelanggaran kesegaran akan mengirimkan peringatan (page) ke pemilik dan menandai produk data sebagai basi (stale). Kegagalan deskripsi yang tidak kritis dapat dilanjutkan dengan metrik. Kontrak harus menyatakan siapa yang dapat mengesampingkan batasan (override gate), untuk berapa lama, dan bukti apa yang diperlukan.
Jangan membuang rekaman secara diam-diam. Lacak jumlah yang diterima, ditolak, dikarantina, diputar ulang, dan duplikat berdasarkan produsen dan versi kontrak. Pemutaran ulang harus bersifat idempoten, sehingga sink menggunakan ID event dan versi kontrak untuk menghindari timbulnya efek bisnis kedua kalinya.
6. Verifikasi model operasi
Jalankan pengujian kontrak pada data pengujian (fixture), pengujian kompatibilitas pada setiap versi yang diajukan, dan validasi canary pada sampel partisi produksi. Uji event yang terlambat, ID duplikat, nilai enum yang tidak dikenal, kolom wajib yang null, kesalahan zona waktu, dan produsen yang berhenti mengirim.
Dasbor yang berguna menggabungkan tingkat pelanggaran, usia kesegaran, kelengkapan, lag konsumen, kedalaman karantina, keberhasilan pemutaran ulang, dan waktu hingga pengakuan (acknowledgement) pemilik. Pemeriksaan skema yang berwarna hijau dengan feed yang basi tetap merupakan produk data yang gagal.
Contoh jawaban berkualitas tinggi
"Saya akan memperlakukan aliran pesanan sebagai produk data berversi. Pertama, saya akan mendaftar para konsumen dan menentukan semantik event: waktu event, unit jumlah, mata uang, identitas, dan transisi status. Kontrak tersebut kemudian akan memuat skema, aturan domain dan relasional, SLO kesegaran dan kelengkapan, kepemilikan, retensi, serta label privasi.
"Registri akan menolak perubahan yang tidak kompatibel di CI. Produsen akan memvalidasi sebelum memublikasikan, sementara validator runtime mengirim rekaman buruk ke karantina beserta aturan yang gagal dan versi kontrak. Konsumen mempertahankan sekumpulan kecil pemeriksaan kritis karena perutean atau transformasi masih bisa salah.
"Saya akan membuat evolusi bersifat aditif secara default. Untuk pengubahan nama atau perubahan semantik, saya akan menambahkan kolom atau versi baru, memublikasikan ganda, memigrasikan konsumen, mengukur pembacaan kolom lama, dan menghentikan versi lama hanya setelah jendela kompatibilitas berakhir. Pelanggaran kesegaran dan kualitas memiliki tingkat keparahan, pemilik, peringatan, dan prosedur pemutaran ulang yang eksplisit. Saya akan memverifikasi desain dengan fixture, canary, event terlambat dan duplikat, serta metrik untuk kesegaran, kelengkapan, kedalaman karantina, dan kebenaran pemutaran ulang."
Kesalahan umum
- Kesalahan → Kegagalan → Solusi: Menganggap skema sebagai keseluruhan kontrak → perubahan semantik dan kepemilikan tetap implisit → dokumentasikan makna, SLO, pemilik, dan kebijakan perubahan.
- Kesalahan → Kegagalan → Solusi: Menolak setiap rekaman yang tidak valid secara sinkron → satu event buruk dapat memblokir seluruh partisi → karantina dengan backpressure terbatas dan kunci pemutaran ulang.
- Kesalahan → Kegagalan → Solusi: Mengklaim kolom aditif selalu aman → konsumen yang ketat mungkin gagal pada kolom yang tidak dikenal → verifikasi kompatibilitas konsumen sebelum mengizinkan perubahan.
- Kesalahan → Kegagalan → Solusi: Hanya memperingatkan ketidakcocokan skema → data yang basi atau tidak lengkap masih dapat lolos pemeriksaan skema → pantau kesegaran, volume, kelengkapan, dan invarian bisnis.
- Kesalahan → Kegagalan → Solusi: Menggunakan kembali nama kolom setelah mengubah maknanya → nilai historis dan baru menjadi tidak dapat dibandingkan → buat versi baru atau kolom yang ditransformasikan secara eksplisit.
Pertanyaan lanjutan dan tanggapan
Bagaimana jika tidak semua produsen dapat melakukan pembaruan secara bersamaan?
Biarkan kontrak lama tetap aktif, tambahkan kolom atau versi baru, dan terima keduanya selama jendela waktu yang terukur. Adaptor kompatibilitas dapat menerjemahkan input lama, tetapi harus mengekspos hilangnya konversi dan tanggal penghentian alih-alih menyembunyikan perbedaannya.
Bagaimana jika uji kontrak berhasil tetapi metriknya tetap salah?
Itu adalah pergeseran semantik. Tambahkan invarian tingkat bisnis atau pemeriksaan rekonsiliasi, bandingkan dengan sumber independen, dan catat definisi yang diperselisihkan dalam kontrak. Kompatibilitas struktural tidak dapat membuktikan bahwa produsen telah menerapkan aturan bisnis yang benar.
Bagaimana cara mencegah karantina menjadi kuburan data?
Beri setiap aturan seorang pemilik dan target kedaluwarsa, pertahankan payload asli dan versi kontrak, serta ukur usia antrean dan keberhasilan pemutaran ulang. Tinjauan harian harus mengklasifikasikan kegagalan sebagai bug produsen, cacat kontrak, atau pengecualian yang diharapkan.
Kapan Anda akan menghindari penggunaan data contract?
Untuk tabel privat berumur pendek dengan satu pemilik dan tanpa komitmen downstream, skema ringan dan pengujian mungkin lebih murah. Terapkan kontrak yang lebih lengkap ketika banyak tim, pemutaran ulang, kolom yang diatur regulasi, atau komitmen kesegaran membuat asumsi implisit menjadi berisiko.