Perintah dan ruang lingkup
Pertanyaan desain sistem ini ditujukan untuk peran platform, infrastruktur cloud, dan embedded system. Perangkat dapat offline selama berminggu-minggu, memiliki penyimpanan terbatas, atau membayar biaya bandwidth seluler; image yang buruk dapat memutus koneksi seluruh armada. Platform harus memastikan bahwa hanya perangkat yang kompatibel yang menginstal paket yang ditandatangani, bahwa peluncuran dapat dijeda, dan bahwa perangkat dapat pulih atau kembali ke versi sebelumnya.
Asumsikan satu juta perangkat, maksimal 100.000 unduhan per hari, dan pembaruan sebesar 20 MiB. Kelompokkan perangkat berdasarkan model, revisi perangkat keras, wilayah, dan versi saat ini. Jawaban tidak memerlukan AWS; produk cloud hanya membantu memperjelas batasan control-plane dan data-plane.
Apa yang dievaluasi pewawancara
- Apakah Anda memisahkan integritas paket, autentikasi penerbit, otorisasi perangkat, dan pemeriksaan kompatibilitas.
- Apakah Anda merancang state machine untuk control-plane dan data-plane perangkat alih-alih hanya menggambar bucket unduhan.
- Apakah Anda menghitung bandwidth, konkurensi, dan ambang batas penghentian serta menjelaskan jeda, percobaan ulang (retry), rollback, dan eskalasi manusia.
Jawaban yang kuat mendefinisikan "peluncuran yang berhasil" sebagai verifikasi perangkat, instalasi, reboot, dan konfirmasi kesehatan, bukan sekadar penyelesaian unduhan CDN.
Klarifikasi sebelum menjawab
- Bisakah perangkat melakukan boot dari dua slot? Slot A/B memungkinkan penulisan ke slot yang tidak aktif dan kembali (fallback) setelah boot gagal; perangkat slot tunggal memerlukan bootloader yang lebih konservatif dan jalur pemulihan di lapangan (field-recovery).
- Apakah ada batasan keamanan atau regional? Penargetan harus mencakup model, perangkat keras, wilayah, status sertifikat, dan versi saat ini, bukan hanya label perangkat.
- Berapa batas waktu pembaruan? Batas waktu mengubah ukuran batch, jendela pemeliharaan (maintenance windows), percobaan ulang offline, dan apakah instalasi paksa dapat diterima.
- Apakah kegagalan terjadi di tingkat perangkat atau tingkat kohort? Perangkat individual dapat mencoba lagi; tingkat kegagalan yang lebih tinggi untuk satu model harus menjeda kohort tersebut alih-alih meluas secara global.
Jawaban 30 detik
"Saya akan membagi platform menjadi repositori paket bertanda tangan, control plane rilis, agen perangkat, dan telemetri. Pipeline rilis membuat manifes dengan model, perangkat keras, versi, dependensi, dan masa kedaluwarsa, menandatanganinya di lingkungan yang terkontrol, dan membuat perangkat memverifikasi tanda tangan, digest, serta kompatibilitas sebelum instalasi. Control plane menargetkan kohort dengan peluncuran canary, laju tetap, atau eksponensial dan menyimpan status per perangkat dengan ID pekerjaan yang idempoten. Perangkat mengunduh potongan data (chunks) secara resumable ke dalam slot yang tidak aktif, me-reboot, dan melakukan commit hanya setelah pemeriksaan kesehatan berhasil. Peningkatan kegagalan, kesalahan unduhan, rollback boot, atau peringatan keamanan akan menjeda kohort dan mempertahankan versi lama. Perangkat offline mencoba lagi di jendela pemeliharaan, dan setiap tindakan dapat diaudit serta diputar ulang (replayable)."
Jawaban mendalam langkah demi langkah
Langkah 1: Perkirakan hambatan utama (bottleneck).
Jika satu juta perangkat mengunduh 20 MiB, totalnya sekitar 20 TiB. Menyelesaikan 100.000 perangkat per hari adalah sekitar 2 TiB/hari, atau rata-rata 23,7 MiB/s; saat puncak membutuhkan ruang cadangan untuk konkurensi dan percobaan ulang. Penyimpanan objek dan CDN mendistribusikan paket. Control plane mengirimkan manifes dan otorisasi unduhan berdurasi pendek daripada membuat perangkat melakukan polling ke database besar.
Langkah 2: Buat paket dan manifes yang autentik.
Pipeline build menghasilkan byte yang tidak dapat diubah (immutable), sebuah digest, dan sebuah manifes. Kunci penandatanganan tetap berada di layanan penandatanganan yang terkontrol, dan rilis mencatat versi penanda tangan serta persetujuan. Perangkat memiliki trust root dan memverifikasi tanda tangan, digest paket, model target, bootloader minimum, counter anti-rollback, dan masa kedaluwarsa. URL unduhan adalah mekanisme transport, bukan batas kepercayaan (trust boundary).
Langkah 3: Pisahkan control plane dan data plane.
Control plane membuat rilis, menyelesaikan target, membuat kohort dan pekerjaan perangkat, serta mengeluarkan perintah jeda. Data plane perangkat mengunduh potongan data dari CDN dan melaporkan status ke endpoint pekerjaan. Setiap perangkat memperbarui (device_id, job_id) secara idempoten, sehingga laporan duplikat tidak dapat memindahkan status secara salah. Status mencakup QUEUED, DOWNLOADING, VERIFIED, INSTALLING, SUCCEEDED, FAILED, ROLLED_BACK, dan REJECTED.
Langkah 4: Rancang instalasi dan rollback yang aman.
Tulis paket ke slot yang tidak aktif, verifikasi setiap potongan dan manifes akhir, lalu alihkan slot boot. Bootloader mencatat percobaan dan batas waktu konfirmasi boot. Aplikasi mengonfirmasi hanya setelah pemeriksaan kesehatan, sensor kritis, dan komunikasi pulih. Kegagalan berulang akan memilih slot lama dan melaporkan alasannya. Perangkat slot tunggal memerlukan image pemulihan atau layanan lapangan; perangkat tersebut tidak mendapatkan atomisitas A/B secara otomatis.
Langkah 5: Kontrol peluncuran.
Mulai dengan perangkat internal dan canary kecil, lalu perluas berdasarkan model dan wilayah. Laju tetap maupun eksponensial keduanya valid, tetapi setiap kohort memerlukan konkurensi maksimum, jendela pemeliharaan, dan kriteria penghentian. Ukur ambang batas per kohort dan pisahkan kegagalan unduhan, penolakan tanda tangan, kegagalan instalasi, rollback boot, dan batas waktu pemeriksaan kesehatan.
Langkah 6: Tangani perangkat offline, percobaan ulang, dan audit.
Ketika perangkat terhubung kembali, perangkat tersebut mengklaim pekerjaan yang belum kedaluwarsa. Unduhan terfragmentasi (chunked) menggunakan resume dan exponential backoff; percobaan ulang menggunakan kembali pekerjaan dan versi paket yang sama. Perangkat yang melewati batas waktunya masuk ke antrean remediasi alih-alih ditandai berhasil. Control plane mempertahankan persetujuan, manifes, snapshot target, transisi status, pelaku (actor), dan alasan jeda untuk pemutaran ulang dan kepatuhan.
Contoh jawaban berkualitas tinggi
"Saya akan memisahkan control plane, repositori paket/CDN, agen perangkat, dan telemetri. Pipeline rilis membuat byte yang tidak dapat diubah dan manifes yang berisi model target, revisi perangkat keras, bootloader minimum, counter versi, dan digest; layanan penandatanganan yang terkontrol menandatanganinya, dan perangkat memverifikasinya dengan embedded trust root. URL unduhan hanya mentransmisikan byte.
Dengan satu juta perangkat, paket 20 MiB berukuran sekitar 20 TiB, sehingga CDN menangani distribusi sementara control plane menyimpan rilis dan status pekerjaan per perangkat. Perangkat mengunduh potongan data ke dalam slot yang tidak aktif, memverifikasi digest, me-reboot, dan melakukan commit hanya setelah konfirmasi kesehatan; kegagalan akan memilih slot lama dan melaporkan alasannya. Saya mulai dengan canary, lalu memperluas berdasarkan model dan wilayah. Setiap kohort memiliki ambang batas konkurensi, tingkat kegagalan, dan tingkat rollback; melampaui salah satunya akan menjeda peluncuran alih-alih menyebarkan image yang rusak. Perangkat offline mengklaim pekerjaan yang sama dalam jendela pemeliharaan, percobaan ulang dilanjutkan, serta persetujuan, status, dan versi tetap dapat diaudit."
Kesalahan umum
- Hanya memeriksa HTTPS → keamanan transport tidak mengautentikasi paket atau bytenya → verifikasi tanda tangan manifes dan digest paket pada perangkat.
- Menandai berhasil setelah unduhan → pemeriksaan instalasi, boot, dan kesehatan masih bisa gagal → jadikan konfirmasi boot sebagai syarat akhir keberhasilan.
- Meluncurkan ke seluruh armada sekaligus → satu cacat kompatibilitas dapat memengaruhi semua orang → gunakan canary, kohort, laju peluncuran, dan kriteria penghentian.
- Membuat pekerjaan baru pada setiap percobaan ulang → riwayat status dan audit menjadi terfragmentasi → gunakan kembali status
(device_id, job_id)yang idempoten. - Mengizinkan downgrade sembarangan → penyerang dapat memutar ulang (replay) image yang rentan → gunakan signed version counters, kebijakan anti-rollback, dan daftar pengecualian yang terkontrol.
Tindak lanjut dan tanggapan
Tindak Lanjut 1: Pada 2% peluncuran, satu model mencapai tingkat boot-rollback sebesar 4%. Apa yang Anda lakukan?
Jeda model dan versi paket tersebut segera sambil terus mengamati perangkat yang berhasil. Buat irisan data (slice) berdasarkan revisi perangkat keras, bootloader, wilayah, dan build untuk menemukan batas kompatibilitas; jika perlu, terapkan versi lama yang terverifikasi atau perintah pemulihan. Jangan melanjutkan hanya karena rata-rata seluruh armada masih rendah.
Tindak Lanjut 2: Perangkat kehilangan daya pada proses unduh 80%. Bagaimana upaya berikutnya menghindari memulai dari awal?
Tulis potongan data ke dalam slot yang tidak aktif dan simpan secara persisten versi paket, digest potongan data, offset yang dikonfirmasi, serta digest manifes keseluruhan. Setelah reboot, verifikasi potongan data lokal dan manifes, lalu minta rentang data mulai dari potongan tepercaya terakhir yang berurutan. Jika paket atau tanda tangan berubah, buang slot sementara alih-alih menggabungkan dua versi.
Tindak Lanjut 3: Bagaimana Anda menghentikan penyerang memutar ulang (replay) paket lama yang valid?
Sertakan monotonic version counter atau versi keamanan dalam manifes dan simpan nilai tertinggi yang diterima di perangkat secara persisten; bootloader akan menolak nilai yang lebih rendah. Rollback darurat memerlukan tanda tangan terkontrol, kohort eksplisit, dan otorisasi dengan batas waktu yang dicatat dalam audit, sehingga endpoint unduhan biasa tidak dapat melewati anti-rollback.