Wawancara system design: Bagaimana Anda membangun platform A/B yang mendeteksi kegagalan kualitas eksperimen?

Petunjuk dan konteks

Sebuah organisasi produk menjalankan ratusan uji A/B setiap hari. Platform ini menetapkan pengguna, mencatat paparan, menghitung metrik, dan memantau kualitas. Eksperimen sebelumnya mengalami masalah alokasi yang tidak merata, ketidaksesuaian rasio sampel (sample-ratio mismatch atau SRM), dan kesimpulan tidak valid akibat pengintipan berulang kali (repeated peeking). Rancang sistem dari konfigurasi eksperimen hingga peninjauan keputusan, termasuk penundaan data, statistik, peringatan (alerts), dan izin.

Hal yang diuji oleh pewawancara

• Apakah kandidat mengklarifikasi unit eksperimentasi, tingkat pengacakan, bidang saling eksklusif (mutual-exclusion planes), dan definisi metrik.
• Apakah mereka memisahkan peristiwa penugasan (assignment), pemicu (trigger), paparan (exposure), dan hasil (outcome).
• Apakah mereka merancang pemeriksaan pengacakan, deteksi SRM, dan peringatan kualitas data.
• Apakah mereka memahami bahwa uji berjangka tetap (fixed-horizon test) tidak dapat diintip secara bebas dan mampu mengusulkan metode sekuensial atau anytime-valid.
• Apakah peringatan, audit, eksekusi ulang (reruns), dan gerbang rilis (release gates) membentuk satu alur kerja yang terpadu.

Pertanyaan klarifikasi untuk diajukan terlebih dahulu

1. Apakah pengacakan dilakukan berdasarkan pengguna, perangkat, sesi, atau permintaan? Bisakah eksperimen berjalan secara ortogonal?
2. Berapa banyak eksperimen dan pengguna yang berjalan setiap hari, serta bagaimana latensi metrik dan jendela retensinya?
3. Bagaimana metrik utama, guardrail, dan efek minimum yang dapat dideteksi (minimum detectable effects) dideklarasikan?
4. Setelah terjadi SRM atau hilangnya data paparan, apakah lalu lintas harus dijeda, pengujian dibatalkan, atau dijalankan ulang?
5. Siapa yang dapat memeriksa penugasan, mengubah aturan penghentian, dan menyetujui peluncuran?

Jawaban 30 detik

“Saya akan membagi platform menjadi konfigurasi dan pengacakan, pengumpulan peristiwa, analisis, dan gerbang keputusan. Penugasan menggunakan hash yang stabil untuk memetakan pengguna ke bucket dan memisahkan eksperimen yang saling eksklusif dari eksperimen ortogonal. Jalur peristiwa mencatat status assigned, triggered, exposed, dan outcome. Layanan kualitas secara berkelanjutan memeriksa distribusi bucket dan SRM, sementara analisis menggunakan metode sekuensial atau anytime-valid untuk pemantauan dan penghentian. Setiap keputusan memuat versi data, kode, dan audit; peringatan kualitas akan memblokir rilis, bukan hanya menjadi pesan di obrolan.”

Jawaban mendalam langkah demi langkah

1. Menentukan batasan eksperimen dan pengacakan

Konfigurasi mencakup ID eksperimen, versi, unit, pembagian lalu lintas, bidang saling eksklusif, metrik target, guardrail, efek minimum yang dapat dideteksi, dan aturan penghentian. Hash menggunakan kunci unit yang stabil dan seed eksperimen sehingga satu pengguna tidak berganti varian di setiap permintaan. Pengujian yang saling eksklusif berbagi satu bidang; pengujian ortogonal menggunakan bidang terpisah dan mencatat kebijakan tabrakan (collision policy).

2. Memisahkan penugasan dari peristiwa hasil

Hanya mencatat konversi tidak dapat membuktikan bahwa pengguna melihat varian tersebut. Peristiwa harus mencakup penugasan, pemicu, paparan, dan hasil beserta versi eksperimen, varian, waktu, hash unit anonim, dan sumber. Berikan versi pada skema peristiwa, izinkan peristiwa yang terlambat masuk ke jendela komputasi ulang, dan lakukan deduplikasi dengan kunci idempotensi.

{
  "experiment": "checkout-copy-v3",
  "experimentVersion": 7,
  "unitHash": "u_8f2c",
  "variant": "treatment",
  "event": "exposure",
  "eventTime": "2026-08-01T12:00:03Z",
  "schemaVersion": 2,
  "idempotencyKey": "u_8f2c:checkout-copy-v3:7:exposure"
}

Peristiwa yang tidak dapat diubah (immutable) dan pengidentifikasi versi menghubungkan penugasan dengan analisis, sehingga perubahan konfigurasi tidak dapat menafsirkan ulang data historis secara keliru.

3. Memantau pengacakan dan SRM

Pemeriksaan pengacakan membandingkan distribusi bucket dengan ekspektasi. Pemeriksaan SRM membandingkan sampel terpicu yang diamati dengan rasio yang dikonfigurasi. Periksa tingkat penugasan maupun pemicu karena kelayakan, versi klien, atau instrumentasi dapat menimbulkan bias setelah penugasan dilakukan. Peringatan harus membedakan penundaan data sementara, cacat alokasi nyata, dan perubahan lalu lintas, sembari tetap mempertahankan irisan diagnostik (diagnostic slices).

4. Menangani observasi berkelanjutan dan penghentian

Uji berjangka tetap yang diperiksa setiap hari dan dihentikan ketika hasilnya signifikan akan meningkatkan kesalahan Tipe I (Type I error). Gunakan metode sekuensial kelompok, SPRT, atau urutan kepercayaan anytime-valid (anytime-valid confidence sequences), serta catat batas, alfa, beta, MDE, dan waktu observasi dalam versi eksperimen. Pemilik produk yang melihat hasil unggul tidak dapat melewati gerbang statistik; kegagalan guardrail atau pelanggaran batas keamanan harus menghentikan lalu lintas terlebih dahulu.

5. Merancang jalur streaming dan batch

Jalur streaming mengonsumsi peristiwa mirip Kafka dan memperbarui peringatan kualitas alokasi serta latensi data dalam hitungan menit. Jalur batch melakukan deduplikasi, memperbaiki data yang terlambat, menghitung irisan data, dan menghasilkan laporan akhir. Keduanya berbagi skema, versi eksperimen, dan definisi metrik. Hasil streaming bersifat sementara; hanya watermark batch yang menjadikannya bukti valid untuk rilis.

6. Menghubungkan keputusan ke audit dan gerbang rilis

Status eksperimen mencakup draft, running, paused, invalid, concluded, dan archived. Mengubah seed, metrik, atau aturan penghentian akan membuat versi baru dan membekukan hasil lama. Layanan keputusan mengeluarkan watermark data, metode, ukuran sampel, status SRM, status guardrail, dan tautan audit. Rilis hanya menerima versi berstatus concluded yang telah lolos pemeriksaan kualitas.

Contoh jawaban berkualitas tinggi

“Saya pertama-tama akan mengunci unit pengacakan dan versi eksperimen, kemudian memisahkan peristiwa penugasan, pemicu, paparan, dan hasil. Pengacakan menggunakan hash yang stabil serta bidang saling eksklusif atau ortogonal. Pipeline peristiwa menggunakan versi skema dan kunci idempotensi untuk mengatasi duplikasi, data terlambat, dan pemutaran ulang (replay). Layanan kualitas memeriksa distribusi bucket dan SRM pada tingkat penugasan dan pemicu serta mengekspos irisan akar penyebab. Uji berjangka tetap tidak boleh dirusak oleh pengintipan sembarangan, sehingga analisis menggunakan metode sekuensial atau anytime-valid serta mencatat batas dan waktu observasi. Data streaming menjalankan peringatan, sementara watermark batch menghasilkan laporan. Keputusan menyertakan versi konfigurasi, kode, data, dan audit; SRM, paparan yang hilang, atau kegagalan guardrail akan memblokir rilis.”

Kesalahan umum

• Hanya menyimpan metrik akhir → hilangnya alokasi atau paparan menjadi tidak terlihat → pertahankan penugasan, pemicu, paparan, dan hasil.
• Mengacak setiap permintaan, bukan setiap pengguna → satu pengguna melihat beberapa varian → gunakan kunci unit yang stabil dan seed.
• Memeriksa p-value setiap hari dan berhenti lebih awal → asumsi jangka tetap menjadi rusak → gunakan metode sekuensial atau anytime-valid.
• Menyebut SRM sebagai hasil signifikansi keluaran → rasio yang tidak normal dapat membatalkan pengujian → jeda keputusan lalu diagnosis alokasi dan kelayakan.
• Mendorong rilis langsung dari data streaming → data terlambat dan duplikat dapat menulis ulang kesimpulan → wajibkan watermark batch dan gerbang rilis.

Pertanyaan lanjutan dan jawaban

Mengapa harus memeriksa sampel yang ditugaskan dan sampel yang terpicu?

Penugasan bisa saja seragam, tetapi hanya pengguna yang memenuhi syarat yang mencapai halaman tersebut yang memicu pengujian. Logika kelayakan, versi klien, pencegat (interceptors), atau peristiwa paparan yang hilang dapat mendistorsi rasio pemicu. Kedua tingkat tersebut membedakan kerusakan pada pengacakan dari kerusakan pada jalur paparan.

Bagaimana Anda mendukung pengujian yang saling eksklusif dan ortogonal?

Pengujian yang saling eksklusif berbagi bidang lalu lintas dan seed, sehingga pengguna hanya masuk ke satu pengujian di bidang tersebut. Pengujian ortogonal menggunakan bidang terpisah dan dapat digabungkan, tetapi platform mencatat matriks tabrakan dan menonaktifkan kombinasi yang berisiko.

Masalah apa yang diselesaikan oleh metode anytime-valid?

Metode ini memungkinkan pemantauan berkelanjutan dan penghentian yang bergantung pada data sambil memberikan kontrol kesalahan yang seragam terhadap waktu (time-uniform error control). Platform tetap mendeklarasikan efek target, daya statistik (power), guardrail, dan kerugian bisnis; metrik arbitrer dan alasan penghentian subjektif tidak dapat berubah menjadi jaminan statistik.

Haruskah kegagalan SRM memicu eksekusi ulang otomatis?

Bekukan keputusan dan pertahankan data mentah terlebih dahulu. Lakukan pemotongan (slice) berdasarkan waktu, klien, negara, kelayakan, dan bidang untuk menemukan penyebabnya. Jalankan ulang hanya setelah alokasi atau instrumentasi diperbaiki dan pemilik produk menyetujui jendela analisis yang baru; eksekusi ulang otomatis tidak boleh menyembunyikan eksperimen yang tidak valid.