Wawancara System Design: Mendesain Layanan Penyimpanan dan Sinkronisasi File Cloud

Prompt dan skenario yang berlaku

Desain layanan penyimpanan file cloud dan sinkronisasi multi-perangkat yang mirip dengan Dropbox atau Google Drive. Layanan ini memiliki 50 juta pengguna terdaftar dan 5 juta pengguna aktif harian. Setiap pengguna menyimpan rata-rata 10 GB data logis. Sistem menerima 100 juta versi file baru per hari, dengan 4 MB konten baru atau yang diubah per versi. Lalu lintas puncak adalah lima kali rata-rata harian. File dapat berukuran hingga 50 GB, perangkat online harus melihat pembuatan, pembaruan, pemindahan, dan penghapusan dalam waktu 5 detik, dan layanan metadata menargetkan ketersediaan 99,99%.

Skala, latensi, ketersediaan, dan target ukuran chunk 4 MiB adalah asumsi wawancara, bukan komitmen performa publik dari produk penyimpanan mana pun. Cakupannya mencakup upload, download, transfer yang dapat dilanjutkan, pemulihan versi, sinkronisasi multi-perangkat, pengeditan offline, salinan konflik, berbagi sederhana, dan penghapusan. Pengeditan kolaboratif tingkat karakter, penggabungan dokumen Office secara semantik, sistem otorisasi enterprise yang lengkap, dan penulisan lintas wilayah aktif-aktif berada di luar cakupan.

Prompt system design publik pada tahun 2026 masih menggunakan Dropbox, Google Drive, atau layanan sinkronisasi file generik untuk menanyakan tentang chunking file besar, delta sync, versi, operasi offline, dan konflik. Dokumentasi resmi object-storage juga menetapkan nilai rekayasa dari multipart upload: bagian-bagian file dapat diunggah secara paralel dan bagian yang gagal dapat dicoba kembali secara independen, sementara bagian yang ditinggalkan memerlukan pembatalan (abort) atau pembersihan siklus hidup (lifecycle cleanup). Wawancara ini bertujuan untuk memisahkan transfer konten dari status namespace dan menutup loop kebenaran seputar pemulihan dan penghapusan, bukan menghafal arsitektur internal satu perusahaan.

Apa yang dievaluasi oleh pewawancara

Pertama, dapatkah kandidat memisahkan konten file dari metadata? Urutan bita (byte) yang besar harus ditempatkan di object storage yang tahan lama (durable), murah, dan immutable. Nama, hubungan induk-anak (parent-child), versi saat ini, penanda penghapusan (deletion marker), dan kursor sinkronisasi memerlukan penulisan kondisional dan perubahan yang terurut. Menempatkan file 50 GB dalam database relasional, atau menggunakan object key sebagai model direktori lengkap, membuat pembaruan, pemindahan, commit transaksi, dan pemulihan menjadi rentan bermasalah.

Kedua, apakah ada satu titik publikasi yang eksplisit untuk sebuah upload? Klien dapat mengunggah chunk yang hilang secara paralel, tetapi versi tersebut hanya terlihat setelah server memverifikasi setiap chunk dan memperbarui currentVersionId secara atomik dengan change log. Jika tidak, metadata dapat mereferensikan konten yang hilang, atau bita yang diunggah mungkin tidak akan pernah terlihat oleh pengguna.

Ketiga, dapatkah protokol sinkronisasi bertahan dari notifikasi yang hilang, duplikat, dan urutannya berubah? Pesan push hanyalah petunjuk (hint) bahwa ada sesuatu yang berubah. Perangkat harus menggunakan kursor yang tahan lama untuk menarik (pull) perubahan otoritatif. Perangkat yang offline selama berhari-hari, klien yang diinstal ulang, dan kursor yang kedaluwarsa semuanya memerlukan jalur pemulihan. Koneksi WebSocket bukanlah sumber kebenaran (source of truth).

Keempat, apakah semantik konkurensinya jujur? Ketika dua perangkat offline memodifikasi file biner biasa yang sama dari versi lama yang sama, layanan generik tidak dapat menggabungkannya secara andal. Commit kondisional yang gagal harus mempertahankan kedua hasil dan membuat salinan konflik alih-alih secara diam-diam menggunakan strategi last-writer-wins. Dokumentasi bantuan publik Dropbox juga menjelaskan bahwa pengeditan simultan atau offline dapat menghasilkan conflicted copy yang harus digabungkan oleh pengguna.

Terakhir, apakah jawabannya menghubungkan kapasitas, biaya, dan reklamasi? Kandidat harus membedakan kapasitas logis dari kapasitas fisik yang telah dideduplikasi, memperkirakan commit versi dan throughput bita, serta menjelaskan chunk yatim (orphan chunk), versi yang dipertahankan, deletion tombstone, kuota, hotspot namespace, dan mengapa garbage collection tidak dapat hanya mengandalkan satu penghitungan referensi instan.

Pertanyaan klarifikasi sebelum menjawab

• Konten apa yang disinkronkan? File dan direktori biasa; tidak ada kolaborasi langsung tingkat karakter.
• Konsistensi apa yang diperlukan? Perangkat yang mengunggah mendapatkan perilaku read-your-write; perangkat online lainnya konvergen dalam 5 detik.
• Berapa lama riwayat inkremental dipertahankan? Asumsikan 30 hari; kursor yang lebih lama memerlukan snapshot namespace sebelum melanjutkan delta.
• Bagaimana pengeditan bersamaan (concurrent edits) ditangani? Hanya satu commit dari baseVersionId tertentu yang menjadi versi saat ini; hasil yang lebih baru dipertahankan sebagai salinan konflik.
• Bisakah penghapusan langsung mereklamasi bita seketika? Tidak. Tulis tombstone dan pertahankan selama 30 hari untuk sinkronisasi offline dan pemulihan.
• Apakah deduplikasi bersifat global di seluruh pengguna? Buat default deduplikasi dengan cakupan akun atau penyewa (tenant) untuk mengurangi kebocoran keberadaan konten dan keterikatan enkripsi.
• Berbagi (sharing) seperti apa yang masuk dalam cakupan? Tautan hanya-baca untuk file atau direktori; izin organisasi yang kompleks adalah pembahasan lanjutan.
• Bagaimana enkripsi dan file berbahaya ditangani? Enkripsi dalam transit dan saat istirahat (at rest), signed URL berumur pendek, dan pemindaian malware asinkron; enkripsi end-to-end berada di luar cakupan.
• Bagaimana region menerima penulisan? Setiap namespace memiliki satu home write region; objek dapat direplikasi lintas region dan metadata memiliki replikasi disaster-recovery asinkron.
• Apakah instant-upload hit dijamin? Tidak ada rasio deduplikasi tetap yang diasumsikan. Bebankan kuota logis berdasarkan ukuran yang terlihat oleh pengguna dan ukur penghematan fisik secara terpisah.

Kerangka jawaban 30 detik

\"Saya akan menyimpan chunk immutable berukuran sekitar 4 MiB di object storage dan menyimpan direktori, versi saat ini, manifes, tombstone, dan perubahan terurut dalam metadata yang konsisten kuat. Klien hanya mengunggah chunk yang hilang, lalu melakukan commit secara atomik dengan baseVersionId dan kunci idempoten (idempotency key). Perangkat mempertahankan kursor dan menggunakan notifikasi hanya untuk memicu /changes?cursor=, sehingga notifikasi yang hilang tidak menghilangkan data. Commit offline bersamaan mempertahankan salinan konflik. Pada 100 juta versi per hari, puncak lima kali lipat adalah sekitar 6.000 commit/detik, sementara 400 TB ingress harian mencapai puncaknya mendekati 25 GB/detik. Penghapusan mempertahankan tombstone, dan chunk hanya direklamasi setelah masa tenggang (grace period) dan rekonsiliasi manifes.\"

Pembahasan mendalam langkah demi langkah

Mulailah dengan lima invarian:

1. Versi yang dipublikasikan hanya mereferensikan chunk yang ada dan lulus pemeriksaan integritas.
2. Commit menggantikan currentVersionId hanya jika baseVersionId masih sama dengan versi saat ini.
3. Nomor urut perubahan meningkat secara ketat di dalam namespace, dan kursor perangkat hanya maju ke depan.
4. Penghapusan menulis tombstone; data yang mungkin masih direferensikan tidak dihapus secara fisik selama jendela sinkronisasi dan pemulihan.
5. Garbage collection menghapus chunk hanya setelah masa tenggang dan rekonsiliasi manifes tetap tidak menunjukkan adanya referensi.

Langkah satu: pisahkan klien, metadata plane, dan content plane.

Klien memiliki file watcher, indeks lokal, jurnal operasi yang tahan lama, chunker, dan sync engine. Setelah terjadi crash, klien memulihkan chunk mana yang telah diunggah dan commit mana yang belum pasti alih-alih memindai ulang dan mengunggah setiap file. Server memiliki API gateway, pemeriksaan autentikasi dan kuota, layanan metadata, koordinator upload, object storage, change log namespace, layanan notifikasi, CDN download, pemindai malware, dan garbage collector.

Metadata dirutekan berdasarkan namespaceId. Drive pribadi adalah satu namespace, dan folder bersama dapat menjadi namespace lain, menjaga otorisasi, perubahan terurut, dan isolasi hotspot di dalam satu batas. Setiap namespace awalnya memiliki satu home write region dengan replikasi metadata sinkron di seluruh availability zone. Download dapat menggunakan CDN terdekat atau replika objek. Ini menghindari dua leader regional menerima pembaruan direktori yang berkonflik secara bersamaan.

Langkah dua: definisikan model data.

FileEntry(id, namespaceId, parentId, name, type, currentVersionId, deletedAt)
FileVersion(id, fileId, baseVersionId, size, manifestHash, createdBy, createdAt)
VersionChunk(versionId, ordinal, chunkHash, size)
UploadSession(id, fileId, baseVersionId, state, expiresAt, idempotencyKey)
Change(namespaceId, seq, entityId, operation, versionId, createdAt)

Pohon direktori menggunakan nilai fileId dan parentId yang stabil, sehingga pemindahan atau penggantian nama mengubah metadata tanpa menyalin konten. FileVersion bersifat immutable, dan baris-baris VersionChunk yang terurut membentuk manifesnya. manifestHash memvalidasi manifes tetapi tidak menggantikan checksum dari setiap chunk. UploadSession menyimpan status sesi dan kunci idempotennya. Change.seq bersifat monotonik di dalam namespace, dan penghapusan adalah operasi lain yang dicatat dalam log.

Terapkan keunikan nama dengan batasan kondisional pada (namespaceId, parentId, normalizedName). Produk harus mendefinisikan normalisasi huruf besar/kecil (case normalization) secara eksplisit; jika tidak, klien Windows, macOS, dan Linux dapat berselisih tentang apakah dua nama berkonflik atau tidak.

Langkah tiga: desain resumable multipart upload.

POST /files/{fileId}/upload-sessions
  { baseVersionId, size, chunks[], idempotencyKey }
  -> { uploadSessionId, missingChunks[], signedUrls[] }

PUT {signedChunkUrl}
  Content-Checksum: ...

POST /upload-sessions/{uploadSessionId}/commit
  { manifestHash, idempotencyKey }
  -> { fileVersionId, changeSeq }

GET /files/{fileId}/download-manifest
  -> { fileVersionId, chunks[], signedUrls[] }

Klien memulai dengan chunk berukuran sekitar 4 MiB dan menghitung hash yang kuat. Server mencari chunk yang ada hanya di dalam akun atau tenant dan menerbitkan signed URL berumur pendek dengan cakupan objek dan operasi untuk chunk yang hilang. Klien mengunggah dengan paralelisme terbatas dan hanya mencoba kembali bagian yang gagal. Dokumentasi multipart resmi AWS dan Alibaba Cloud keduanya menggunakan model sesi inisiasi, upload bagian, dan penyelesaian (complete). Mereka juga mencatat bahwa bagian yang belum selesai terus menggunakan penyimpanan, sehingga sesi memerlukan waktu kedaluwarsa dan upload yang telah lama ditinggalkan memerlukan pembatalan eksplisit.

Chunk berukuran tetap sederhana dan dapat diparalelkan dengan baik untuk sebagian besar file. Jika beban kerja sering menyisipkan beberapa bita di dekat awal, setiap batas tetap berikutnya akan bergeser dan hash-nya berubah. Content-defined chunking dapat memulihkan lebih banyak data yang tidak berubah dengan mengorbankan CPU dan kompleksitas implementasi. Mulailah dengan chunk tetap dan tingkatkan hanya jika pola pengeditan yang diamati membenarkannya.

Langkah empat: jadikan commit versi sebagai satu-satunya batas publikasi.

Endpoint commit pertama-tama mencari hasil yang ada berdasarkan idempotencyKey, kemudian memvalidasi ukuran chunk, hash, otorisasi, dan kuota. Dalam satu transaksi metadata, sistem:

1. Mengunci atau membaca FileEntry.currentVersionId secara kondisional.
2. Memverifikasi bahwa nilainya masih sama dengan baseVersionId dari permintaan.
3. Menulis manifes FileVersion dan VersionChunk yang immutable.
4. Memperbarui currentVersionId.
5. Menambahkan Change.seq berikutnya dan catatan transactional outbox.

Bita objek selesai sebelum transaksi metadata, sehingga transaksi tidak dapat mempublikasikan referensi ke chunk yang hilang. Kegagalan notifikasi setelah commit tidak memengaruhi kebenaran data: outbox mencoba kembali, dan perangkat masih dapat menarik berdasarkan kursor. Jika respons commit hilang, mencoba kembali dengan kunci idempoten yang sama akan mengembalikan fileVersionId asli alih-alih membuat versi logis lain atau menagih kuota dua kali.

Langkah lima: sinkronkan perangkat dengan kursor.

GET /changes?namespaceId={id}&cursor={lastSeq}&limit=1000
  -> { changes[], nextCursor, hasMore }

Perangkat menyimpan lastSeq dan indeks file lokalnya dalam transaksi tahan lama yang sama. Setelah notifikasi \"namespace mungkin telah berubah\", perangkat menarik hingga hasMore=false, menerapkan pembuatan, pembaruan, pemindahan, dan tombstone secara berurutan, dan baru kemudian meng-commit kursor baru. seq membuat pemutaran ulang (replay) menjadi idempoten. Notifikasi yang urutannya berubah tidak memengaruhi hasil penarikan. Jika setiap notifikasi hilang, aktivasi latar depan (foreground wakeups) dan pemeriksaan berkala masih dapat menemukan urutan yang lebih baru.

Jika kursor lebih lama dari jendela retensi 30 hari, layanan mengembalikan cursor_expired dengan lokasi snapshot namespace yang konsisten. Klien memuat snapshot, merekonsiliasi operasi lokal yang belum di-commit, dan melanjutkan dari watermark snapshot. Klien tidak boleh langsung menghapus semua file lokal. Notifikasi adalah optimasi latensi; log kursor adalah protokol sinkronisasi sebenarnya.

Langkah enam: tangani konflik, penghapusan, dan pemulihan versi.

Perangkat A dan B sama-sama mengedit versi 10 secara offline. A meng-commit versi 11 dengan baseVersionId=10. Commit kondisional B berikutnya gagal. Layanan mempertahankan konten yang diunggah B, membuat entri baru seperti \"name (B's conflicted copy)\" atau versi konflik, dan menambahkan perubahan namespace. File biner biasa tidak digabungkan secara otomatis tanpa konfirmasi. Penggabungan khusus teks atau dokumen adalah kemampuan produk yang terpisah.

Penghapusan memperbarui deletedAt dan menambahkan tombstone. Perangkat online memindahkan entri ke tempat sampah (trash), dan perangkat offline dapat mengetahui tentang penghapusan tersebut saat terhubung kembali. Versi historis dan referensi chunk tetap valid selama jendela pemulihan 30 hari. Setelah itu, kolektor menghitung kumpulan chunk yang direferensikan oleh manifes yang dipertahankan, menandai kandidat yang tidak direferensikan, menunggu masa tenggang, dan merekonsiliasi kembali sebelum menghapus. Percobaan ulang, peristiwa yang tertunda, dan tugas perbaikan dapat membuat penghitungan referensi instan menjadi salah, sehingga tidak dapat menjadi otoritas tunggal untuk penghapusan yang tidak dapat dibatalkan.

Langkah tujuh: estimasi kapasitas dan isolasi hotspot.

50 million × 10 GB = 500 PB penyimpanan logis. Replikasi, riwayat, dan deduplikasi mengubah kapasitas fisik, tetapi prompt tidak memberikan rasio, sehingga angka fisik yang tepat hanyalah rekaan. Ingress logis harian adalah 100 million × 4 MB = 400 TB, dengan rata-rata sekitar 4,6 GB/detik dan memuncak di sekitar 25 GB/detik. Commit versi rata-rata 100,000,000 / 86,400 ≈ 1,157/s dan dibulatkan menjadi sekitar 6.000/detik pada puncak lima kali lipat.

Jika setiap perubahan memberi petunjuk kepada rata-rata tiga perangkat online, notifikasi dapat mencapai puncaknya mendekati 18.000/detik. Notifikasi dapat digabungkan menjadi \"namespace ini berubah\" daripada menjadi pesan per-file yang andal. Shard metadata dengan hash berdasarkan namespaceId, menjaga penulisan terurut untuk satu namespace pada satu shard primer. Ruang bersama yang sangat besar dapat menjadi hot. Batasi laju operasi direktori massal (bulk rate-limit), gabungkan notifikasi, dan lakukan sub-sharding catatan file berdasarkan fileId hanya jika ada bukti yang jelas, sambil tetap mempertahankan generator urutan namespace yang terpisah.

Langkah delapan: tutup loop kegagalan, keamanan, dan validasi.

• Upload terputus: kueri sesi dan unggah hanya bagian yang hilang; pemrosesan siklus hidup akan menghentikan sesi yang ditinggalkan.
• Bagian berhasil diunggah tetapi commit gagal: bagian tersebut adalah orphan sementara dan rekonsiliasi manifes akan mereklamasinya setelah masa tenggang.
• Commit berhasil tetapi notifikasi gagal: transactional outbox mencoba kembali, dan penarikan kursor tetap memulihkan data.
• Commit berhasil tetapi respons hilang: kunci idempoten yang sama mengembalikan hasil asli.
• Penulisan offline bersamaan: kondisi baseVersionId gagal dan layanan mempertahankan salinan konflik.
• Chunk rusak: upload dan download memverifikasi hash yang kuat, dan konten yang tidak valid tidak dapat masuk ke manifes yang dipublikasikan.
• Kursor kedaluwarsa: muat snapshot, lalu lanjutkan dari watermark-nya.
• Home region tidak dapat menulis: hentikan penulisan atau lakukan failover di bawah prosedur RPO/RTO yang eksplisit; jangan pernah mengizinkan dua home writer.

Signed URL harus berumur pendek dan terikat pada akun, objek, ukuran, dan operasi. Server memeriksa ulang otorisasi dan kuota saat commit. Upload instan global lintas pengguna menciptakan side-channel untuk keberadaan konten serta menggabungkan hak enkripsi dan penghapusan per pengguna, sehingga deduplikasi secara default dicakup per tenant. Metrik inti mencakup p99 upload dan commit, lag sinkronisasi, kursor kedaluwarsa, salinan konflik, bita chunk orphan, dedup hit, perbedaan kandidat versus penghapusan GC, hotspot namespace, kegagalan checksum, dan keberhasilan pemulihan.

Validasi mencakup transfer yang dapat dilanjutkan untuk file 50 GB, crash setelah setiap tahap upload, commit duplikat, notifikasi yang hilang dan urutannya berubah, pengeditan offline bersamaan, perangkat lama yang kembali aktif setelah penghapusan, kerusakan checksum, failover shard primer, kursor kedaluwarsa, batas kuota, dan perlindungan GC terhadap penghapusan yang salah. Asersi end-to-end yang paling penting adalah bahwa setiap fileVersionId yang terlihat dapat diunduh menjadi konten yang lengkap dan terverifikasi, dan versi di dalam jendela pemulihan tidak pernah direklamasi.

Contoh jawaban berkualitas tinggi

\"Saya pertama-tama akan memisahkan content plane dari metadata plane. File dipecah menjadi chunk immutable berukuran sekitar 4 MiB di object storage. Direktori, nilai fileId yang stabil, versi saat ini, manifes versi, tombstone, dan nomor urut namespace berada di lapisan metadata yang mendukung penulisan kondisional. Pemindahan dan penggantian nama memperbarui metadata tanpa menimpa riwayat.

Selama upload, klien melakukan hashing chunk dan membuat sesi dengan baseVersionId serta kunci idempoten. Server mengembalikan signed URL berumur pendek hanya untuk chunk yang hilang dengan cakupan tenant. Setelah semua chunk diunggah dan diverifikasi, transaksi metadata memastikan bahwa versi saat ini tidak berubah, menulis versi dan manifes baru, memperbarui currentVersionId, dan menambahkan Change.seq ditambah catatan outbox. Konten selesai sebelum publikasi metadata, sehingga versi yang terlihat tidak pernah mengarah ke bita yang hilang. Respons yang hilang dipulihkan dengan kunci idempoten yang sama.

Sinkronisasi menggunakan kursor yang tahan lama. Notifikasi hanya menyatakan bahwa namespace mungkin telah berubah. Perangkat memanggil /changes?cursor=, menerapkan perubahan secara berurutan, lalu memajukan kursor. Oleh karena itu, notifikasi yang hilang, duplikat, dan urutannya berubah tidak akan menghilangkan data. Kursor yang lebih lama dari jendela retensi 30 hari akan dibangun kembali dari snapshot yang konsisten dan dilanjutkan dari watermark-nya. Ketika dua perangkat mengedit versi yang sama secara offline, commit yang lebih lambat akan mempertahankan salinan konflik alih-alih menimpa versi yang lebih baru.

Kapasitasnya adalah 500 PB penyimpanan logis. Konten baru atau yang diubah adalah 400 TB per hari, rata-rata sekitar 4,6 GB/detik dan memuncak di sekitar 25 GB/detik. Seratus juta versi rata-rata sekitar 1.157 commit per detik dan memuncak mendekati 6.000/detik. Metadata di-shard berdasarkan namespace dengan satu home write region, sementara download diskalakan melalui CDN dan replika objek regional.

Penghapusan menulis tombstone yang dipertahankan selama 30 hari. Ketika riwayat kedaluwarsa, garbage collection menandai kandidat dari semua manifes yang dipertahankan, menunggu masa tenggang, dan merekonsiliasi kembali. Sistem tidak pernah menghapus hanya karena satu penghitungan referensi mencapai nol. Saya akan menginjeksikan kegagalan di setiap batas upload dan commit, kemudian memverifikasi notifikasi yang hilang, konflik offline, kursor kedaluwarsa, kerusakan checksum, failover primer, dan keamanan GC sambil terus memastikan bahwa setiap versi yang terlihat dapat diunduh sepenuhnya.\"

Kesalahan umum

• Menyimpan bita file di database metadata → objek besar membebani replikasi, cadangan (backup), dan transaksi → simpan referensi dalam metadata dan konten immutable di object storage.
• Mempublikasikan file setelah bagian pertama diunggah → perangkat lain dapat membaca versi yang tidak lengkap → commit metadata secara atomik hanya setelah setiap bagian diverifikasi.
• Memperlakukan notifikasi WebSocket sebagai kebenaran sinkronisasi → pesan yang hilang atau periode offline membuat perubahan terlewatkan secara permanen → gunakan notifikasi hanya untuk memicu penarikan kursor otoritatif.
• Melakukan commit tanpa baseVersionId → perangkat offline secara diam-diam menimpa versi yang lebih baru → gunakan conditional commit dan pertahankan salinan konflik saat gagal.
• Menghasilkan sesi dan kunci idempoten baru pada setiap percobaan ulang → versi duplikat, tagihan kuota, dan orphan bertambah → gunakan kunci yang stabil untuk memulihkan hasil asli.
• Menggunakan default upload instan global lintas pengguna → keberadaan konten bocor dan hak enkripsi/penghapusan menjadi terikat → batasi cakupan deduplikasi ke akun atau tenant.
• Menghapus chunk segera setelah pengguna melakukan penghapusan → sinkronisasi offline, pemulihan, atau transaksi yang tertunda akan mereferensikan bita yang hilang → gunakan tombstone, retensi, masa tenggang, dan rekonsiliasi.
• Mengasumsikan rasio deduplikasi tetap untuk kapasitas fisik → beban kerja yang tidak diketahui menghasilkan presisi palsu → laporkan 500 PB logis dan kalibrasi penghematan fisik dari pengukuran nyata.
• Mendorong setiap perubahan file secara andal ke setiap perangkat → biaya notifikasi dan status percobaan ulang meledak → gabungkan petunjuk namespace dan biarkan klien menarik delta.
• Memulai dengan penulisan metadata lintas wilayah aktif-aktif → konflik nama, pemindahan, dan versi saat ini menjadi sulit untuk dikonvergensikan → pertahankan satu home writer per namespace terlebih dahulu.

Pertanyaan lanjutan dan tanggapan

Lanjutan satu: Bagaimana Anda memilih antara chunk berukuran tetap versus content-defined chunk?

Chunk berukuran sekitar 4 MiB sederhana dan dapat diprediksi serta bekerja dengan baik untuk append, penimpaan terlokalisasi, dan sebagian besar file media. Jika pengguna sering menyisipkan konten di dekat awal, batas tetap akan bergeser dan setiap hash berikutnya berubah. Content-defined chunking dapat menemukan kembali konten yang tidak berubah tetapi menggunakan lebih banyak CPU dan memerlukan algoritma batas berversi yang stabil. Luncurkan dengan chunk tetap, ukur persentase bita yang dapat digunakan kembali setelah pengeditan, dan aktifkan content-defined chunking untuk file besar tertentu hanya jika penghematan yang diamati membenarkan kompleksitasnya.

Lanjutan dua: Bagaimana pemindahan direktori mempertahankan urutan sinkronisasi?

Pemindahan memperbarui parentId dan menambahkan satu urutan namespace dalam transaksi metadata. Klien menerapkannya berdasarkan seq. Pemindahan tidak menulis ulang jalur untuk setiap turunannya (descendant) karena jalur diturunkan dari rantai induk. Pemindahan lintas-namespace tidak dapat dianggap sebagai satu pembaruan metadata lokal; modelkan itu sebagai alur kerja salin-dan-hapus yang dapat dicoba kembali dan tampilkan status sedang berlangsung kepada pengguna.

Lanjutan tiga: Bagaimana enkripsi end-to-end dan upload instan dapat hidup berdampingan?

Dengan enkripsi end-to-end di sisi klien, server umumnya hanya melihat ciphertext. Kunci per-pengguna yang berbeda membuat plaintext yang identik menghasilkan ciphertext yang berbeda, menghilangkan sebagian besar deduplikasi lintas-pengguna. Enkripsi konvergen memperkenalkan serangan konfirmasi konten dan risiko kunci. Produk harus memilih: mode privasi tinggi menerima deduplikasi yang lebih rendah, sementara mode kunci yang dikelola tenant dapat melakukan deduplikasi di dalam tenant. Sistem tidak dapat menjanjikan upload instan global tanpa syarat dan kerahasiaan end-to-end yang kuat pada saat yang sama.

Lanjutan empat: Bagaimana jika satu direktori bersama yang sangat besar menjadi hot?

Pertama gabungkan notifikasi, batasi laju operasi massal, simpan halaman direktori hanya-baca di cache, dan ukur apakah hambatannya adalah alokasi urutan, keunikan nama, atau listing direktori. Metadata file dapat di-sub-shard berdasarkan fileId, tetapi namespace masih memerlukan watermark yang terurut. Secara internal, alokasikan rentang urutan secara batch atau gunakan log yang dipartisi sambil menampilkan kursor eksternal yang stabil. Jangan membuang semantik pengurutan yang dapat dipulihkan hanya untuk mengklaim skala horizontal.

Lanjutan lima: Bagaimana garbage collection menghindari penghapusan yang salah?

GC tidak mempercayai penghitungan referensi langsung saja. GC membangun kumpulan data aktif (live set) dari setiap manifes yang masih berada dalam retensi, menandai chunk di luar kumpulan tersebut sebagai kandidat, menunggu lebih lama dari penundaan transaksi, replikasi, dan pemulihan maksimum, serta merekonsiliasi terhadap manifes saat ini sebelum menghapus. Penghapusan bersifat idempoten dan diaudit; manifes yang hilang atau ketidakcocokan akan menunda reklamasi. Bagian multipart yang belum selesai juga memerlukan kedaluwarsa sesi dan pemrosesan pembatalan yang independen.

Lanjutan enam: Bagaimana Anda menyediakan disaster recovery lintas wilayah?

Setiap namespace biasanya memiliki satu home region yang menerima penulisan metadata. Wilayah lain mereplikasi log dan objeknya secara asinkron. Failover pertama-tama membatasi (fence) writer lama, mempromosikan replika pemulihan di bawah epoch baru, dan mengubah perutean. RPO bergantung pada lag replikasi dan RTO pada deteksi dan promosi. RPO nol memerlukan kuorum lintas wilayah yang sinkron dan latensi tulis yang lebih tinggi. Primary lama yang dipulihkan harus memvalidasi epoch kepemimpinan namespace sebelum menerima penulisan.

Lanjutan tujuh: Bagaimana Anda membuktikan bahwa sinkronisasi tidak pernah kehilangan data?

Bangun model status yang menghasilkan urutan upload, commit, pemindahan, penghapusan, konflik, dan percobaan ulang. Pastikan bahwa klien setelah menerapkan urutan N sama dengan snapshot server pada N. Pengujian end-to-end secara acak menghapus, menduplikasi, dan mengubah urutan notifikasi tanpa merusak change log; perangkat harus tetap konvergen melalui penarikan kursor. Injeksikan crash setelah menerapkan perubahan tetapi sebelum menyimpan kursor, dan setelah menyimpan konten lokal tetapi sebelum penyelesaian proses. Pemutaran ulang harus tetap idempoten, dan setiap perangkat pada akhirnya harus mencapai grafik versi yang sama.