Belajar System Design - Design Distributed File Storage (Dropbox/Google Drive)

#Pendahuluan

Setelah di episode 23 kita mendesain distributed rate limiter, pada episode ini kita mendesain distributed file storage seperti Dropbox atau Google Drive. Ini adalah case study yang menarik karena ia menggabungkan storage (chunk-based), sync (delta sync), metadata management, dan conflict resolution — semua tantangan utama distributed systems.

File storage bukan hanya tentang menyimpan file — ia tentang sync otomatis antar device, menangani conflict saat dua device mengedit file yang sama, dan memastikan versi file bisa di-restore. Inilah yang membuatnya challenging dan menarik untuk system design.

#Requirements

#Functional Requirements

Upload/download: user bisa upload dan download file.
Auto-sync: perubahan di satu device otomatis sync ke device lain.
File versioning: setiap perubahan disimpan sebagai versi baru.
Conflict resolution: jika dua device edit file yang sama secara bersamaan.
Sharing: share file/folder ke user lain.

#Non-Functional Requirements

Reliability: file tidak boleh hilang.
Consistency: file yang di-sync antar device harus identik.
Efficiency: sync hanya transfer bagian yang berubah (delta).
Scale: 500M users, 10B files, 1EB total storage.

#Arsitektur

#Chunk Storage

Chunk-based file storage

File 100MB → di-split menjadi chunks:
  Chunk 1: 0-4MB (hash: abc123)
  Chunk 2: 4-8MB (hash: def456)
  Chunk 3: 8-12MB (hash: ghi789)
  ...
 
Storage: S3/R2 (object storage)
Key: chunks/{hash}

Kelebihan chunk storage:

Delta sync: hanya upload chunks yang berubah.
Deduplication: chunk yang sama di-share antar file.
Efficient storage: tidak perlu store file utuh.

#Metadata Database

Metadata schema (PostgreSQL)

CREATE TABLE files (
    file_id UUID PRIMARY KEY,
    owner_id UUID NOT NULL,
    filename VARCHAR(255),
    file_path TEXT,
    is_folder BOOLEAN DEFAULT FALSE,
    parent_id UUID REFERENCES files(file_id),
    latest_version INTEGER DEFAULT 1,
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP DEFAULT NOW()
);
 
CREATE TABLE file_versions (
    file_id UUID REFERENCES files(file_id),
    version INTEGER,
    chunk_hashes TEXT[],  -- array of chunk hashes
    size BIGINT,
    checksum VARCHAR(64),
    created_at TIMESTAMP DEFAULT NOW(),
    PRIMARY KEY (file_id, version)
);
 
CREATE TABLE chunks (
    chunk_hash VARCHAR(64) PRIMARY KEY,
    ref_count INTEGER DEFAULT 1,
    storage_path TEXT,
    size BIGINT
);

#Delta Sync

Delta sync flow

Device A edit file:
1. Client detect file change (filesystem watcher)
2. Client compute new chunk hashes
3. Compare dengan chunk hashes di server
4. Upload hanya chunks yang berbeda (new/changed)
5. Server update metadata: file → new version → new chunk list
6. Server notify其他 devices via WebSocket
 
Device B receive notification:
1. Download delta (hanya chunks baru/berubah)
2. Reconstruct file dari existing chunks + new chunks
3. File di Device B updated

#WebSocket untuk Notifikasi

Real-time sync notification

Device A → edit file → save ke server
Server → WebSocket → notify Device B, C, D: "file X updated"
Device B, C, D → download delta → update local file

#Conflict Resolution

#Last-Write-Wins (LWW)

LWW conflict resolution

Device A: edit file → save (timestamp: 10:00:01)
Device B: edit file → save (timestamp: 10:00:02)
 
LWW: timestamp lebih baru menang
→ Device B's version yang dipilih
→ Device A's changes HILANG (data loss!)

#Three-Way Merge

Three-way merge

Base version: V1 (last sync)
Device A edit → V2A
Device B edit → V2B
 
Merge: bandingkan V2A dan V2B dengan V1 sebagai base
- Jika hanya A yang berubah: take V2A
- Jika hanya B yang berubah: take V2B
- Jika keduanya berubah di bagian berbeda: merge otomatis
- Jika keduanya berubah di bagian SAMA: conflict → user harus pilih

#CRDT untuk File Metadata

CRDT untuk concurrent operations

Operation: { type: "insert", position: 5, char: "x" }
Operation: { type: "delete", position: 10 }
 
CRDT merge: kedua operasi bisa di-apply tanpa conflict
→ Character-level CRDT (seperti Automerge/Yjs)

Note

Untuk file content conflict, three-way merge adalah approach yang paling practical. CRDT digunakan untuk collaborative editing real-time (Google Docs). LWW sederhana tapi menyebabkan data loss — gunakan hanya untuk metadata, bukan content.

#Penutup

Inti yang harus dibawa pulang:

Chunk storage: file di-split → chunks → object storage; enables delta sync dan deduplication.
Delta sync: hanya transfer chunks yang berubah — sangat efficient untuk file besar.
Metadata DB: file tree, versions, chunk references — PostgreSQL untuk ACID.
Conflict resolution: three-way merge untuk file content; LWW untuk metadata; CRDT untuk collaborative editing.
WebSocket: real-time notification untuk sync antar device.

Di episode 25 selanjutnya kita akan membahas observability & monitoring di scale — tiga pilar (metrics, logs, traces), alerting strategies, dan setup observability stack. Observability adalah kemampuan memahami apa yang terjadi di dalam sistem — tanpa ini, debugging di production seperti mencari jarum di tumpukan jerami!