System Design
Case Study: Dropbox
- **Languages**: Python (backend), Rust (Sync Engine rewrite), Go (infrastructure) - **Storage**: Custom block storage on commodity hardware (Magic Pocket) - **Database**: MySQL (sharded), EdgeStore (distributed metadata) - **Queue**: Kafka for event streaming - **Cache**: Memcache, Redis - **Network**: Custom protocol 'Sync' over HTTP/2
**Маленькие блоки (1MB)**: - ✅ Лучшая дедупликация - ❌ Больше metadata overhead - ❌ Больше I/O операций **Большие блоки (16MB)**: - ✅ Меньше metadata - ❌ Хуже дедупликация - ❌ Больше bandwidth при малых изменениях **Dropbox выбор**: 4MB как баланс
В 2016 Dropbox мигрировал с S3 на собственное хранилище Magic Pocket: - **90%** данных хранится в Magic Pocket - **10%** в AWS (для disaster recovery) - Экономия ~75M/год по сравнению с S3 - Exabyte-scale на commodity hardware
Архитектура Sync Engine
Архитектура Sync Engine
Зачем это нужно?
Dropbox синхронизирует миллиарды файлов между устройствами. Понимание архитектуры sync engine критично для любой системы, работающей с файлами локально и в облаке.
Что это такое?
Dropbox использует desktop client с локальной базой данных, который отслеживает изменения файловой системы и синхронизирует их через block server. Архитектура разделяет metadata (информация о файлах) и block data (содержимое файлов).
Как это работает?
Пример
**Пример sync flow:** ```typescript // User edits document.docx locally // 1. File watcher detects change // 2. Sync engine computes new blocklist // 3. Only changed blocks uploaded // 4. Metadata service notified // 5. Other devices receive notification // 6. They download only changed blocks // Efficiency: editing 1KB in 100MB file // → Upload only 1-2 blocks (4-8MB) not entire file ```
Что вы узнали о Архитектура Sync Engine?
Content-Addressed Storage и Дедупликация
Content-Addressed Storage и Дедупликация
Зачем это нужно?
Dropbox хранит 500+ эксабайт данных. Без дедупликации это было бы невозможно экономически. Content-addressed storage позволяет хранить каждый уникальный блок только один раз.
Что это такое?
Каждый блок данных адресуется по его криптографическому хэшу (SHA-256). Если два пользователя загружают одинаковый файл или даже одинаковые части файлов - данные хранятся только один раз.
Как это работает?
Пример
**Реальные цифры Dropbox:** ``` Deduplication savings: - Average file: 1.7 versions stored - Cross-user dedup: ~25% for documents - Cross-version dedup: ~70% for edited files - Overall storage efficiency: ~50% (store half of logical size) Popular files (OS installers, software): - Same Ubuntu ISO uploaded by 10,000 users - Stored only ONCE = massive savings ```
Что вы узнали о Content-Addressed Storage и Дедупликация?
Алгоритмы Chunking
Алгоритмы Chunking
Зачем это нужно?
Выбор алгоритма разбиения файла на блоки критически влияет на эффективность дедупликации. Фиксированный размер блока - простой, но плохо работает при вставках. Content-defined chunking решает эту проблему.
Что это такое?
Dropbox использует content-defined chunking (CDC) на основе rolling hash (Rabin fingerprint). Границы блоков определяются содержимым файла, а не фиксированными позициями. Это обеспечивает стабильные границы при локальных изменениях.
Как это работает?
Пример
**Сравнение алгоритмов:** ``` Algorithm Speed Dedup Efficiency ───────────────────────────────────────────── Fixed-size Fast Poor on inserts Rabin fingerprint Medium Good FastCDC Fast Good BuzHash Fast Good Dropbox uses: Rabin with 4MB target chunks Backblaze B2: FastCDC with variable targets Restic backup: CDC with 1-8MB chunks ```
Что вы узнали о Алгоритмы Chunking?
Metadata и File Journal
Metadata и File Journal
Зачем это нужно?
Metadata service - сердце Dropbox. Он отслеживает все файлы, версии, sharing и обеспечивает консистентность между устройствами. Journal позволяет эффективно синхронизировать изменения.
Что это такое?
Server File Journal (SFJ) - это append-only лог всех изменений. Каждое устройство помнит свою позицию в журнале и запрашивает только новые изменения. Это позволяет эффективно обнаруживать и синхронизировать изменения.
Как это работает?
Пример
**Delta sync в действии:** ```typescript // Device comes online after being offline async function syncFromServer(lastCursor: bigint): Promise<void> { while (true) { const changes = await metadataService.poll(namespaceId, lastCursor, 30000); if (changes.length === 0) { break; // Caught up } for (const change of changes) { await applyRemoteChange(change); lastCursor = change.cursor; } await saveLastCursor(lastCursor); } } // Efficiency: // - Offline for 1 week with 100 changes // - Only fetch those 100 entries, not full directory listing // - ~10KB of metadata, not scanning entire filesystem ```
Что вы узнали о Metadata и File Journal?
Conflict Resolution
Conflict Resolution
Зачем это нужно?
Когда два устройства редактируют один файл оффлайн - возникает конфликт. Dropbox должен сохранить обе версии и позволить пользователю разрешить конфликт вручную.
Что это такое?
Dropbox использует last-writer-wins с сохранением conflicted копий. При обнаружении конфликта проигрывающая версия сохраняется как отдельный файл с именем 'file (conflicted copy DATE)'. Пользователь сам решает, какую версию оставить.
Как это работает?
Пример
**Conflict avoidance strategies:** ```typescript // 1. Optimistic locking for active sessions interface EditSession { fileId: string; userId: string; deviceId: string; startedAt: Date; lastHeartbeat: Date; } // Show warning: "John is currently editing this file" // User can still edit, but is warned about potential conflict // 2. Real-time sync when online // Sync every few seconds while file is open // Reduces window for conflicts // 3. Application-specific handlers // Some apps (Office, Figma) use OT/CRDT // Dropbox provides hooks for these integrations ```
Что вы узнали о Conflict Resolution?