Design Dropbox

Prompt latihan

1. Problem Statement, Functional Requirements, and Scale Assumptions

   Tentukan ruang lingkup layanan file sync: mengunggah file dari klien desktop, menyinkronkan perubahan di beberapa perangkat milik pengguna yang sama, berbagi file dan folder dengan pengguna lain, dan memelihara version history untuk rollback. Kecualikan secara eksplisit pengeditan kolaboratif real-time (gaya Google Docs), office suite bawaan, otomatisasi backup dengan penjadwalan, dan kontrol admin enterprise dari desain awal. Nyatakan asumsi skala awal (file per pengguna, ukuran file rata-rata, volume event sync) sebelum mengusulkan komponen apa pun.

2. Non-Functional Requirements

   Tentukan NFR utama: keandalan sync (tidak ada kehilangan data, file yang diunggah di satu perangkat harus muncul di semua perangkat lain pada akhirnya), latensi sync untuk file kecil (target <5 detik untuk file di bawah 1MB), efisiensi bandwidth (minimalkan transfer data redundan, hanya konten yang berubah yang harus diunggah), semantik penanganan konflik (apa yang terjadi ketika file yang sama diedit di dua perangkat secara offline bersamaan), dan dukungan offline (klien harus berfungsi saat terputus dan sync saat kembali online).

3. Quantitative Analysis

   Estimasikan total storage (pengguna × file per pengguna × ukuran file rata-rata), bandwidth unggah harian (pengguna aktif harian × laju perubahan ukuran file rata-rata × event unggah per hari), volume event sync (event perubahan file per pengguna per hari × pengguna aktif), ukuran metadata store (ukuran baris metadata file × total file), dan penghematan storage deduplikasi (asumsikan N% file terduplikasi antar pengguna pada level block). Turunkan penghematan bandwidth dari delta sync dibandingkan unggah ulang file penuh.

4. API Design

   Tentukan operasi API untuk mengunggah file (chunked, dengan pembuatan pre-signed URL untuk unggah langsung-ke-object-storage), mengunduh file, menyinkronkan perubahan metadata sejak sebuah cursor (daftar file yang berubah sejak sync terakhir), berbagi file atau folder dengan pengguna lain, mengambil version history untuk sebuah file, dan menyelesaikan sebuah konflik. Sertakan bentuk request dan response, protokol sync berbasis cursor, dan bagaimana klien mendeteksi konflik (server mengembalikan 409 dengan metadata konflik saat version mismatch).

5. High-Level Design

   Usulkan komponen utama: klien desktop dengan file system watcher (mendeteksi perubahan file, memelihara state sync lokal), sync service (API sync metadata berbasis cursor), metadata store (metadata file, version history, izin berbagi), block store (object storage untuk konten file yang dipecah menjadi chunk), notification service (mendorong perubahan ke perangkat lain saat file diperbarui), dan CDN untuk akselerasi unduhan file. Telusuri alur dari sebuah edit file di Perangkat A melalui unggah, update metadata, notifikasi lintas-perangkat, dan sync di Perangkat B.

6. Additional High-Level Design Prompts

   Bahas tiga area desain lanjutan: (1) Model izin berbagi, bagaimana izin read-only vs. editor ditegakkan pada jalur unggah maupun unduh (pengecekan izin di lapisan API vs. token akses level-block), bagaimana pencabutan akses dipropagasikan (segera cabut akses API; konten yang sudah diunduh lebih sulit dicabut), dan bagaimana izin level-folder diwariskan oleh file di dalamnya; (2) Versioning dan rollback file, berapa banyak versi diretensi (berdasarkan jumlah, usia, atau total kuota storage), bagaimana metadata versi disimpan (linked list dari record versi di metadata store), dan operasi rollback (arahkan pointer metadata terbaru ke block list versi sebelumnya); (3) Selective sync, bagaimana klien memungkinkan pengguna memilih folder mana yang sync ke perangkat tertentu (berguna untuk perangkat mobile dengan storage terbatas), bagaimana cursor metadata menangani folder yang dikecualikan dari sync di perangkat saat ini.

7. Deep Dives

   Deep dive ke tiga area: (1) Chunking dan deduplikasi file, bandingkan chunking ukuran-tetap (sederhana, dedup buruk untuk konten yang bergeser) vs. content-defined chunking menggunakan Rabin fingerprinting (chunk ukuran-variabel berdasarkan batas konten; dua file dengan bagian teredit yang sama berbagi chunk yang tidak berubah); rancang indeks deduplikasi (hash chunk SHA-256 → key block store) dan estimasikan penghematan storage (rasio dedup 60-70% untuk beban kerja dokumen office tipikal); bahas deduplikasi cross-user (chunk yang sama disimpan sekali secara global) dan implikasi privasi (pengguna tidak dapat menyimpulkan konten file pengguna lain dari hash collision); (2) Penyelesaian konflik sync, bandingkan last-writer-wins (sederhana, secara diam-diam kehilangan perubahan satu pengguna), pembuatan conflict copy (pendekatan Dropbox: simpan kedua versi dengan sufiks konflik, tidak pernah kehilangan data), dan operational transform (benar tetapi sangat kompleks, hanya cocok untuk editor kolaboratif real-time seperti Google Docs yang secara eksplisit di luar ruang lingkup); bahas pengurutan sync multi-perangkat menggunakan counter versi logis atau Lamport timestamp per file untuk mendeteksi edit bersamaan; (3) Optimasi bandwidth, delta sync hanya mentransmisikan chunk yang berubah (bukan seluruh file) dengan klien menghitung block manifest dan server hanya mengembalikan hash block yang hilang atau berubah; kompresi LZ4 atau zstd per-chunk mengurangi transfer lebih jauh; prioritisasi unggah mengantrikan file kecil terlebih dahulu (langsung terlihat) sementara file besar diunggah chunked di latar belakang; dukungan pause/resume untuk unggahan besar menggunakan session ID multipart upload pre-signed untuk melanjutkan dari chunk terakhir yang di-ack.

8. Final Review Handoff Readiness

   Ringkas keputusan desain end-to-end: strategi chunking (ukuran-tetap vs. content-defined), arsitektur deduplikasi, model penyelesaian konflik (conflict copy), protokol delta sync, teknik optimasi bandwidth, dan kebijakan retensi versi. Soroti dua failure mode terbesar yang tersisa (indeks dedup menjadi bottleneck untuk throughput tulis pada skala masif, dan proliferasi conflict copy yang membanjiri storage untuk folder bersama yang sangat kolaboratif) dan berikan rencana rollout: luncurkan dengan chunking ukuran-tetap tanpa dedup dulu, ukur distribusi storage, lalu tambahkan content-defined dedup secara bertahap.

Preview solusi

Design Dropbox (File Sync Service), Solusi Referensi 1. Scope dan Non-Goals Dalam scope: Desktop client dengan file system watcher, upload file ke object storage, sinkronisasi metadata cross-device via cursor, berbagi file dengan permission, version history, dan penanganan konflik. Non-goals: Pengeditan kolaboratif real-time (gaya Google Docs), office suite …