Petunjuk dan ruang lingkup
Pertanyaan desain sistem frontend ini menggabungkan manajemen state dan pembaruan terdistribusi. Jawabannya harus menghubungkan data lokal, antrean mutasi (mutation queue), versi server, dan status pemulihan yang terlihat alih-alih sekadar menambahkan cache.
Apa yang sedang diuji oleh pewawancara
- Memisahkan draf lokal, mutasi yang tertunda (pending), dan state yang dikonfirmasi server.
- Memilih strategi konflik dan mengidentifikasi bidang yang tidak dapat digabungkan secara otomatis (auto-merge).
- Menangani percobaan ulang (retry), pengiriman duplikat, browser yang ditutup, dan banyak tab.
- Membuat status offline, sinkronisasi, konflik, dan kegagalan mudah dipahami serta dapat dipulihkan.
Pertanyaan klarifikasi yang perlu diajukan
Tanyakan apakah bidang-bidang bersifat independen dan apakah ada yang diaudit atau berisiko tinggi, seperti uang. Klarifikasi lampiran, dukungan versi server atau log operasi, apakah last-write-wins dapat diterima, dukungan browser, dan persyaratan retensi lokal.
Jawaban 30 detik
Saya akan menggunakan IndexedDB sebagai penyimpanan lokal yang tahan lama (durable) dan mencatat setiap pengeditan dengan clientMutationId serta versi server dasar. UI langsung menampilkan hasil lokal dan menandainya sebagai tertunda. Aplikasi atau service worker mengirimkan antrean saat online. Server merespons dengan sukses, konflik, atau kegagalan validasi menggunakan pemeriksaan versi dan idempoten (idempotency). Bidang yang aman dapat digabungkan secara otomatis; bidang berisiko tinggi menampilkan perbedaan (diff) untuk pilihan eksplisit. Setiap status mendukung percobaan ulang atau pembatalan (undo).
Pembahasan mendalam langkah demi langkah
1. Tentukan model state terlebih dahulu
Setiap draf memiliki serverVersion, localVersion, syncState, dan lastError. Setiap mutasi yang tertunda menyimpan clientMutationId, perubahan bidang, waktu pembuatan, dan versi dasar. Pembacaan berasal dari penyimpanan lokal; respons jaringan hanya digabungkan setelah pemeriksaan versi, sehingga respons yang lebih lama tidak dapat menimpa pengeditan yang lebih baru.
2. Pertahankan fakta yang dapat dipulihkan di IndexedDB
IndexedDB cocok untuk data offline terstruktur yang lebih besar, tetapi desainnya harus menangani peningkatan skema, kesalahan kuota, dan penggusuran (eviction) oleh browser. Simpan draf, catatan mutasi, dan konflik secara terpisah, lalu lakukan commit pada draf beserta catatan antreannya dalam satu transaksi. Minimalkan bidang sensitif dan hapus saat logout atau kedaluwarsa.
3. Rancang pemicu sinkronisasi dan idempotensi
Coba langsung saat online dan masukkan ke antrean saat offline. Jika Background Sync didukung, daftarkan tag unik untuk service worker, tetapi jangan menganggap API tersebut sebagai jaminan pengiriman universal. Setiap permintaan membawa clientMutationId dan versi dasar; mengulangi ID yang sama akan menghasilkan hasil yang sama tanpa menerapkan mutasi dua kali.
4. Sesuaikan kebijakan konflik dengan risiko bidang
Bidang independen seperti label dapat digabungkan berdasarkan versi bidang. Uang, izin, dan pernyataan kepatuhan tidak boleh menggunakan last-write-wins secara diam-diam. Saat terjadi konflik, tampilkan nilai lokal, nilai server, dan waktu pengeditan secara berdampingan; pilihan pengguna akan membuat mutasi baru. Penggabungan otomatis harus mencatat inputnya.
5. Tangani kegagalan, percobaan ulang, dan banyak konteks
Gunakan exponential backoff sambil menjaga urutan antrean untuk kegagalan jaringan. Kegagalan validasi menjadi status kesalahan yang dapat diedit, bukan percobaan ulang tanpa batas. Beberapa tab dapat berkoordinasi melalui BroadcastChannel atau pemeriksaan versi sehingga mutasi lama tidak dikirim dua kali. Antrean yang tahan lama dilanjutkan pada peluncuran berikutnya, dan UI menampilkan jumlah yang tertunda serta kesalahan terakhir.
Contoh jawaban yang kuat
Pertama, saya akan menentukan risiko bidang dan batasan offline. Klien menyimpan draf dan antrean mutasi di IndexedDB; setiap mutasi memiliki clientMutationId dan serverVersion dasar, sementara UI langsung menampilkan hasil lokal sebagai tertunda. Aplikasi atau service worker mengirimkan antrean setelah terhubung kembali, dan server mengembalikan status sukses, konflik, atau kesalahan validasi menggunakan pemeriksaan versi dan idempotensi. Bidang independen dapat digabungkan secara otomatis, tetapi bidang berisiko tinggi menampilkan perbedaan lokal-versus-server dan memerlukan konfirmasi. Kegagalan jaringan menerapkan backoff; kegagalan bisnis menjadi dapat diedit. Beberapa tab menggunakan pemberitahuan versi sehingga data usang tidak dapat menimpa pekerjaan yang lebih baru. Antarmuka secara jelas membedakan status offline, sinkronisasi, konflik, kegagalan, dan tersimpan.
Kesalahan umum
- Hanya menyimpan formulir terbaru di cache tanpa antrean mutasi atau versi dasar.
- Menerapkan stempel waktu atau last-write-wins ke setiap bidang.
- Memperlakukan Background Sync sebagai jaminan di setiap browser.
- Mencoba ulang tanpa kunci idempotensi sehingga menciptakan duplikat.
- Hanya mencatat konflik ke konsol tanpa jalur pemulihan bagi pengguna.
- Mengabaikan peningkatan skema, kuota, banyak tab, dan penutupan browser.
Pertanyaan lanjutan dan tanggapan
Bagaimana jika dua tab mengedit pada saat yang sama?
Setiap tab berlangganan perubahan versi dan meminta penggabungan ketika basisnya usang. Periksa kembali versi sebelum mengirim; server tetap melakukan deduplikasi terhadap ID mutasi yang dibagikan.
Bisakah data offline bocor?
Hanya simpan bidang yang diperlukan secara lokal, enkripsi konten sensitif, persingkat retensi, dan hapus saat logout, penggunaan perangkat bersama, atau perubahan kebijakan.
Bagaimana jika browser tidak memiliki Background Sync?
Gunakan peluncuran aplikasi, fokus, perubahan konektivitas, dan short polling sebagai pemicu fallback, dan beri tahu pengguna bahwa rekaman tetap tertunda. Kebenaran sistem tidak boleh bergantung pada API ini.
Kapan penggabungan otomatis aman?
Hanya ketika semantik bidang bersifat independen, versi dasar diketahui, dan perbedaan sementara dapat diterima. Bidang uang, izin, inventaris, dan audit harus memerlukan konfirmasi eksplisit.