Petunjuk dan latar belakang
Event penggunaan yang sama menyuplai batas operasional dan pelaporan keuangan. Event dapat datang terlambat, duplikat, atau dikoreksi, dan satu tenant yang bising tidak boleh menunda tenant lainnya atau membaca data tenant lain.
Hal yang diuji oleh pewawancara
- Memisahkan fakta yang tidak dapat diubah (immutable) dari proyeksi yang dapat diubah (mutable).
- Menentukan idempotensi, jendela waktu event (event-time windows), koreksi, dan finalitas faktur.
- Mendesain isolasi tenant, backpressure, dan bukti rekonsiliasi.
Pertanyaan klarifikasi sebelum menjawab
- Berapa laju event, dimensi, retensi, dan batas waktu finalisasi faktur?
- Apakah penggunaan diukur saat penerimaan permintaan, penyelesaian, atau dampak bisnis yang berhasil?
- Bisakah produsen mengirim ulang ID event, dan bagaimana koreksi atau pengembalian dana (refund) direpresentasikan?
- Keputusan kuota mana yang membutuhkan kesegaran tingkat detik, dan laporan mana yang boleh tertunda?
Kerangka jawaban 30 detik
Saya akan mencatat fakta penggunaan immutable yang dicakup per tenant dengan ID event yang stabil, waktu event, unit, sumber, dan versi skema. Log append-only menyuplai proyeksi kuota dan penagihan yang terpisah. Deduplikasi diberi kunci berdasarkan tenant dan ID event; koreksi adalah fakta baru, bukan penimpaan (overwrite). Pembacaan kuota menggunakan proyeksi cepat yang terbatas, sedangkan faktur ditutup hanya setelah watermark dan tahap rekonsiliasi. Setiap agregat tetap dapat dilacak ke fakta sumber.
Pembahasan mendalam langkah demi langkah
1. Catat faktanya
Autentikasi produsen, validasi cakupan tenant dan unit, lalu simpan event mentah secara persisten sebelum mengirimkan konfirmasi penerimaan (acknowledgment). Wajibkan ID event produsen, sumber, waktu event, dan versi pengukuran. Tolak penulisan yang salah format atau lintas tenant dan pertahankan digest untuk audit.
2. Jadikan penulisan idempoten
Terapkan batasan keunikan (uniqueness constraint) pada (tenant, source, event_id). Duplikat dengan digest yang sama mengembalikan hasil yang ada; digest yang berbeda dikarantina sebagai konflik. Jangan gunakan baris faktur sebagai penyimpanan idempotensi karena percobaan ulang operasional terjadi sebelum penagihan.
3. Proyeksikan kuota dan penagihan secara terpisah
Proyeksi kuota mempertahankan jendela waktu yang singkat, penghitung saat ini, dan kebijakan fail-closed saat tingkat kesegaran tidak diketahui. Penagihan mengagregasikan berdasarkan unit kontraktual dan versi harga, dengan mempertahankan bucket waktu event dan tautan koreksi. Tidak ada proyeksi yang mengedit log fakta immutable.
4. Tangani data terlambat dan tutup faktur
Gunakan watermark berdasarkan waktu event yang diamati ditambah batas keterlambatan yang disepakati. Event setelah watermark masuk ke buku besar penyesuaian dan siklus penagihan atau alur kerja kredit berikutnya. Sebelum finalisasi, rekonsiliasikan hitungan dan jumlah dari log terhadap proyeksi serta catat versi perhitungannya.
5. Operasikan dengan aman
Partisi antrean dan penyimpanan berdasarkan tenant atau kunci pembagian yang adil (fair-share key), terapkan kuota dan backpressure, serta isolasi dead letter. Pantau latensi penyerapan (ingestion lag), tingkat duplikasi dan konflik, usia watermark, pergeseran proyeksi, volume koreksi, dan latensi penutupan faktur. Enkripsi data, batasi ekspor, dan buat setiap koreksi dapat diaudit.
Contoh jawaban berkualitas tinggi
“Saya akan menyimpan fakta penggunaan immutable dengan cakupan tenant yang menyertakan ID event, sumber, waktu event, unit, versi skema dan harga sebelum mengirim konfirmasi. Log append-only menyuplai proyeksi kuota dan penagihan yang independen. Percobaan ulang dengan ID dan digest yang sama bersifat idempoten; digest yang berubah dikarantina. Kuota menggunakan proyeksi cepat yang terbatas, sedangkan faktur ditutup hanya setelah watermark keterlambatan dan rekonsiliasi terhadap fakta sumber. Event yang terlambat menjadi catatan penyesuaian, dan partisi tenant, backpressure, enkripsi, serta metrik pergeseran melindungi kebenaran dan keadilan.”
Kesalahan umum
- Menimpa agregat pada setiap event → data yang terlambat dan koreksi menjadi tidak terlihat → pertahankan fakta dan proyeksi yang immutable.
- Menggunakan waktu kedatangan jam dinding sebagai waktu penggunaan → event yang tertunda masuk ke faktur yang salah → kelompokkan berdasarkan waktu event dan watermark.
- Berbagi satu antrean global → tenant yang bising menciptakan pemblokiran head-of-line → partisi atau terapkan pembagian yang adil.
- Memfinalisasi tanpa rekonsiliasi → pergeseran proyeksi menjadi perselisihan penagihan → bandingkan proyeksi dengan fakta sumber dan berikan versi pada perhitungan.
Pertanyaan lanjutan dan tanggapan
Bagaimana Anda mendukung pengembalian dana atau koreksi?
Tambahkan fakta kompensasi yang ditautkan ke event asli dan versi kontrak. Hitung ulang proyeksi yang terpengaruh atau buat entri buku besar penyesuaian; jangan pernah memodifikasi bukti asli.
Bagaimana jika kuota dan penagihan tidak cocok untuk sementara waktu?
Tetapkan jaminan kesegaran dan finalitas yang terpisah. Kuota dapat berupa perkiraan dalam jendela waktu terbatas, sedangkan penagihan tetap bersifat sementara sampai pemeriksaan watermark dan rekonsiliasi lolos; tunjukkan status tersebut kepada operator dan pelanggan.
Bagaimana Anda mencegah tenant membaca penggunaan tenant lain?
Terapkan cakupan tenant di jalur penulisan, partisi penyimpanan, kueri proyeksi, ekspor, dan alat dukungan. Uji otorisasi di setiap batasan dan catat akses tanpa menyertakan muatan event yang sensitif.