Topik wawancara representatif

Bagaimana Anda mendesain platform telemetri dan analitik produk yang menjaga privasi?

Desain sistemSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Sebuah produk desktop membutuhkan data penggunaan fitur, kategori crash, dan metrik performa kasar tanpa membiarkan platform merekonstruksi linimasa perilaku individu. Desain platform telemetri menyeluruh (end-to-end), mencakup minimalisasi, proteksi klien dan server, granularitas identitas dan waktu, deduplikasi, anggaran, agregasi, latensi, kehilangan data, permintaan penghapusan, kontrol penyalahgunaan, dan verifikasi.

1. Pertanyaan

Sebuah perusahaan ingin memahami penggunaan fitur, kategori crash berdasarkan versi, dan distribusi performa tingkat wilayah untuk klien desktop. Perusahaan tersebut memiliki sekitar 20 juta perangkat aktif per hari, dengan paling banyak 200 event telemetri per perangkat. Tim produk membutuhkan tren agregat dalam waktu 24 jam, sementara tim privasi melarang linimasa perilaku pengguna yang dapat direkonstruksi.

Desain platform telemetri dan analitik yang menjaga privasi. Cakup batasan pengumpulan di sisi klien, format event, anonimisasi atau pengacakan lokal, differential privacy terpusat, batas kontribusi tingkat pengguna, API anggaran dan kueri, keandalan, permintaan penghapusan, izin, dan verifikasi. Jelaskan secara tegas masalah mana saja yang tidak dapat diselesaikan hanya dengan melakukan hashing pada ID.

2. Batasan dan klarifikasi

  • Utamakan pengguna atau perangkat sebagai unit privasi alih-alih memperlakukan setiap event sebagai individu yang independen; jelaskan skenario perangkat bersama dan pengguna multiperangkat.
  • Kumpulkan hanya nama event yang terdaftar, versi, wilayah kasar, bucket performa, dan kategori error yang diperlukan. Jangan mengumpulkan URL mentah, teks bebas, alamat IP lengkap, lokasi presisi, atau muatan konten.
  • Rilis statistik dalam jendela waktu minimal 24 jam dengan supresi kelompok kecil, anggaran differential-privacy, dan audit kueri yang dapat dilacak.
  • Kehilangan data dan keterlambatan dapat diterima, tetapi percobaan ulang (retries), cache, dan replika tidak boleh melipatgandakan kontribusi satu pengguna tanpa batas.

3. Arsitektur tingkat tinggi dan aliran data

SDK klien menerapkan daftar izin (allowlist) event, pemotongan bidang (field clipping), batas nilai, dan pengambilan sampel lokal sebelum menulis batch berversi ke antrean telemetri. Gateway penyerapan (ingestion gateway) memverifikasi tanda tangan, ukuran, jendela waktu, dan laju tanpa menggunakan token akun sebagai kunci analitik. Pemrosesan streaming melakukan deduplikasi tingkat pengguna, pembatasan kontribusi, agregasi jendela waktu, dan pemfilteran anomali. Buffer mentah berumur pendek memiliki TTL yang ketat; penyimpanan jangka panjang hanya menyimpan data perantara agregat yang dilindungi.

text
client SDK
  -> schema/allowlist + local sampling + coarse buckets
  -> encrypted batch with rotating upload token
  -> ingestion gateway (auth, size, rate, replay checks)
  -> stream buffer
  -> privacy transform (user contribution cap, clipping, optional local noise)
  -> aggregate store
  -> DP query service (budget, minimum group, audit)
  -> dashboards and export API

Pengacakan lokal melindungi laporan individual dari pengumpul yang tidak tepercaya tetapi mengurangi akurasi; differential privacy terpusat mempermudah penghitungan anggaran tingkat pengguna untuk agregator internal yang tepercaya. Pendekatan hibrida harus mendefinisikan model ancaman dan jaminan pada setiap lapisan; sekadar menambahkan derau tidak membenarkan klaim privasi yang lebih kuat.

4. Model data, minimalisasi, dan deduplikasi

Sebuah event berisi event_type, versi klien, wilayah kasar, sebuah bucket performa, sebuah bucket waktu-event, dan versi protokol. Sebuah batch unggahan memiliki ID batch acak, masa kedaluwarsa, dan tanda tangan. Server menggunakan kunci internal berumur pendek untuk idempoten dan tidak pernah menulis pengenal pengguna yang stabil ke tabel analitik jangka panjang.

Event berulang dari satu pengguna untuk satu fitur dalam sebuah jendela waktu mengikuti aturan yang telah didaftarkan sebelumnya, seperti maksimal satu kontribusi per pengguna per fitur per hari. Batasan ini harus ditegakkan pada tingkat pengguna, tidak hanya per mesin atau per batch; jika tidak, penyerang dapat memecah batch untuk memotong aturan tersebut. Stack crash, teks error, dan URL harus dimasukkan ke dalam bucket atau dibuang di sisi klien sehingga teks bebas tidak dapat menjadi pengenal tersembunyi.

Permintaan penghapusan memerlukan cakupan yang dapat dieksekusi. Jika penyimpanan jangka panjang hanya berisi agregat ber-differential privacy yang tidak dapat dipulihkan (ireversibel), satu pengguna biasanya tidak dapat dihapus secara presisi dari agregat yang telah dipublikasikan. Sistem harus tetap menghapus buffer mentah berumur pendek, menghentikan pengumpulan data di masa mendatang, dan mendokumentasikan batas ireversibel dari rilis agregat.

5. Anggaran privasi, keandalan, dan API kueri

Layanan kueri melacak anggaran epsilon/delta berdasarkan unit privasi, himpunan data, dan jendela waktu. Setiap kueri resmi memeriksa anggaran, ukuran kelompok minimum, dan dimensi yang diizinkan, kemudian menghasilkan hasil berderau dari tabel agregat berversi dan mencatat entri audit. Percobaan ulang dari kueri logis yang sama harus mengembalikan hasil yang idempoten atau hanya dikenakan biaya satu kali; penambahan dimensi filter dapat menghabiskan anggaran tambahan.

Unggahan menggunakan pengiriman setidaknya sekali (at-least-once delivery). Batch klien dapat melakukan percobaan ulang, gateway melakukan deduplikasi berdasarkan token batch, dan pemrosesan streaming melakukan deduplikasi berdasarkan pengguna dan bucket waktu sambil mengisolasi event terlambat yang belum dikonfirmasi. Kehilangan data, keterlambatan, dan tingkat pengambilan sampel termasuk dalam metrik kualitas data; jika tidak, penurunan pada dasbor dapat salah diartikan sebagai perubahan perilaku produk.

Pada skala 20 juta perangkat dan maksimal 200 event per perangkat per hari, batas atas teoretisnya adalah 4 miliar event per hari. Desain sistem harus menggunakan pengambilan sampel, kompresi batch, dan penyimpanan terpartisi dengan kapasitas cadangan untuk peluncuran versi baru, crash storm, dan pemutaran ulang (replay). Lapisan kueri harus membatasi irisan ber-kardinalitas tinggi, ekspor konkuren, dan operasi join lintas-jendela agar anggaran dan sumber daya komputasi tidak habis secara bersamaan.

6. Pertanyaan lanjutan dan jebakan

  • Apakah ID perangkat yang di-hash bersifat anonim? Hash yang stabil tetap dapat ditautkan di berbagai event dan dapat diidentifikasi ulang dengan data eksternal; lebih baik gunakan token berumur pendek, bidang data yang kasar, dan agregasi tingkat pengguna.
  • Apa perbedaan derau di sisi klien dan terpusat? Model lokal mengurangi kebutuhan kepercayaan pada pihak pengumpul tetapi memiliki varians yang lebih tinggi; model terpusat menyederhanakan pengelolaan anggaran dan kueri jika akses ke agregator dan buffer mentah terkontrol.
  • Bagaimana Anda menangani crash storm? Pengambilan sampel di sisi klien dan pembatasan laju (rate limiting) melindungi pengguna dan sistem penyerapan, gateway mengisolasi versi bermasalah, serta backpressure pada antrean dan kueri yang terdegradasi melindungi sistem hilir; sekadar meningkatkan skala basis data tidaklah cukup.
  • Bisakah platform menjawab pertanyaan analisis apa pun? Tidak. Metrik yang diizinkan dalam daftar, ukuran kelompok minimum, penghitungan anggaran, dan batasan dimensi merupakan kontrak produk; permintaan eksploratif memerlukan persetujuan dan anggaran terpisah.

7. Verifikasi dan metrik operasional

  • Properti privasi: Uji batas kontribusi, kalibrasi derau, komposisi anggaran, dan penolakan kueri pada himpunan data pengguna yang bertetangga; audit parameter untuk setiap versi rilis.
  • Kualitas data: Pantau tingkat pengambilan sampel, cakupan perangkat, tingkat duplikasi, keterlambatan, kehilangan data, distribusi versi, dan kelengkapan jendela waktu, serta rekonsiliasikan dengan data sintetis terkontrol.
  • Keandalan: Suntikkan kegagalan ke dalam sistem penyerapan, antrean, agregator, dan layanan anggaran untuk memverifikasi percobaan ulang yang idempoten, backpressure, karantina, titik pemulihan, dan tidak adanya kebocoran data mentah.
  • Kontrol penyalahgunaan: Uji kueri berdimensi tinggi, ekspor konkuren, anggaran yang habis, eskalasi izin, pemutaran ulang batch, dan injeksi teks bebas, guna memastikan adanya jalur penolakan atau degradasi untuk masing-masing kasus.

8. Poin penilaian wawancara

Mampu menggambarkan batasan privasi dan aliran data

Kandidat harus menyatakan apa saja yang dipercaya, disimpan, dan dihapus oleh klien, gateway, buffer berumur pendek, lapisan agregasi, dan lapisan kueri.

Mampu menerapkan kontrol kontribusi tingkat pengguna

Kandidat harus mencakup deduplikasi pengguna/jendela waktu, batas kontribusi, pemotongan nilai, keidempotenan batch, dan penanganan event terlambat, alih-alih hanya menulis "anonimkan saja".

Mampu mendesain anggaran dan keandalan secara bersamaan

Kandidat harus menyertakan penghitungan epsilon/delta, percobaan ulang yang hanya dikenai biaya satu kali, kelompok minimum, batasan dimensi kueri, backpressure, dan pemulihan dari kegagalan.

Mampu memberikan verifikasi kuantitatif

Kandidat harus menggunakan batas atas 4 miliar event per hari dan mengusulkan pengujian privasi, kualitas data, keandalan, serta penyalahgunaan alih-alih hanya mencantumkan daftar komponen.

Sumber publik

Pertanyaan terkait

Alat wawancara terkait

Gunakan Jawab untuk jawaban desain sistem

Perjelas persyaratan terlebih dahulu, lalu lanjutkan dengan skala, arsitektur, pilihan komponen, dan trade-off.

Lihat alat