Designing a Cloud File Storage System

What you'll learn

• 1. Why Cloud File Storage?

  Cloud file storage gained massive adoption because users now access data from multiple devices — laptops, phones, tablets — across different operating systems and locations. Key benefits: - Availability: Access files from any device, any…

• 2. Requirements Gathering

  > Interview Tip: Always clarify requirements before diving into design. Ask about scale, features, and constraints the interviewer cares about.

• Functional Requirements

  1. Upload and download files from any device 2. Share files or folders with other users 3. Automatic synchronization across devices — edit on one, see it everywhere 4. Support large files (up to 1 GB) 5. ACID guarantees on all file opera…

• Non-Functional Requirements

  - High availability (99.9%+ uptime) - Low latency sync (changes propagate within seconds) - Bandwidth efficiency (don't re-upload unchanged data) - Data security and encryption at rest/in transit ---

• 3. Design Considerations

  Key design decisions to make upfront: - Read/Write ratio: Roughly equal — users both upload and download frequently - Chunking: Split files into fixed-size chunks (~4 MB each) - Failed uploads retry only the failing chunk, not the entire…

• 4. Capacity Estimation

  | Metric | Value | |--------|-------| | Total users | 500 million | | Daily active users (DAU) | 100 million | | Average devices per user | 3 | | Average files per user | 200 | | Average file size | 100 KB | | Total files | 100 billion |…

• 5. High-Level Architecture

  Three core server types: | Component | Responsibility | |-----------|---------------| | Block Server | Handles actual file chunk upload/download to cloud storage | | Metadata Server | Manages file metadata (names, sizes, versions, sharin…

• Design Evolution & Trade-offs

  How this system grew from an MVP to what a production version looks like — and the choices you'd defend in an interview. Cloud file storage is deceptive. On paper it's "upload a blob, download a blob." In practice it's a metadata-heavy,…

• Stage 1 — MVP: One box, one database

  The simplest thing that could possibly work. - A single API server (monolith) that accepts multipart uploads. - A single relational database (Postgres) storing both metadata and — yes, initially — the file bytes in a bytea column or on t…

• Stage 2 — Scale-out: Stateless API + object storage for blobs

  - API tier becomes stateless; N replicas behind an L7 load balancer. - File bytes move to object storage (S3, GCS, Azure Blob) — the API stops touching the filesystem. - Sessions / JWT auth moved out of process memory. - Metadata DB stay…

• Stage 3 — Bottleneck: Chunk transfer, delta sync, and dedup

  This is the first characteristic bottleneck of cloud-file-storage — the one that separates a naive uploader from a real sync service. All three problems (retry-on-failure, bandwidth on small edits, and storage cost for duplicated content…

• Stage 4 — Second bottleneck: Sync fan-out and change notification

  You now have chunking, dedup, and object storage. Users are happy — for about a week. Then Product ships "shared folders." Now Client A edits a file and Clients B, C, D on three different continents need to know within seconds, whether t…

• Stage 5 — Third bottleneck: Metadata at billion-file scale

  Chunking solved bandwidth. Sync fan-out solved notification. Now the wall you hit is the metadata DB. At 500M users × 200 files × ~10 chunks each you're staring at a chunks table with ~1 trillion rows. Postgres can hold a lot, but no sin…

• Stage 6 — Mature architecture

  A view of the full system with all the additions from stages 2–5. The nodes worth calling out specifically: - Regional gateways — sync and API split so a slow WebSocket doesn't starve upload throughput on the same LB pool. - Dedup servic…

• Cost vs Complexity — When to Pick What

  | Concern | MVP choice | Growth choice | Enterprise choice | |---------|-----------|---------------|-------------------| | Compute | Single VM running the monolith | K8s deployment of stateless API + workers | Multi-region K8s with regio…

• Migration Path (MVP → Enterprise)

  A stepped plan. Each step is a self-contained migration you can ship, measure, and roll back — not a big-bang rewrite. 1. Move blobs off the API box → object storage. Blocking prerequisite for horizontal scale-out. Zero user-facing chang…

• 6. Component Deep Dive

• a. Client Application

  The client monitors a designated workspace folder and keeps it in sync with the cloud. Core responsibilities: 1. Upload/download file chunks to/from block storage 2. Detect local changes (file watcher) 3. Handle conflicts from offline or…

• b. Metadata Database

  Stores versioning and metadata about files, chunks, users, and workspaces. Database choice: A relational database (MySQL/PostgreSQL) is preferred because: - Native ACID support simplifies consistency guarantees - Multiple users editing t…

• c. Service Decomposition (LLD Perspective)

  At a low-level design granularity, the server-side can be decomposed into specialized services: | Service | Responsibility | |---------|---------------| | Chunking Service | Splits/reassembles files into chunks; computes hashes; determin…

• d. Synchronization Service

  The most critical component — responsible for: 1. Processing file updates from one client 2. Checking metadata consistency 3. Broadcasting change notifications to all other subscribed clients/devices Key design goals: - Minimize data tra…

• d. Message Queuing Service

  Two queue types: | Queue | Purpose | |-------|---------| | Request Queue | Single shared queue — all clients push update requests here. Sync Service consumes from it. | | Response Queues | One per subscribed client — delivers change noti…

• e. Block / Cloud Storage

  Stores the actual file chunks. Key characteristics: - Clients interact directly with block storage for data upload/download - Metadata is completely separated from file content - This separation allows swapping storage backends (cloud pr…

• 7. File Processing Workflow

  When Client A updates a shared file: If Clients B and C are offline, notifications persist in their Response Queues until they reconnect. ---

• 8. Data Deduplication

  Eliminates redundant data to save storage and bandwidth. For each incoming chunk, compute its hash (SHA-256) and check if an identical chunk already exists.

• Two approaches:

  | Strategy | When Hashing Occurs | Pros | Cons | |----------|-------------------|------|------| | Post-process | After storage — background job scans for duplicates | No upload latency impact | Temporarily stores duplicates; wastes bandw…

• 9. Metadata Partitioning

  With billions of files across millions of users, a single metadata DB server cannot handle the load. Partitioning strategies:

• Strategy Comparison

  | Strategy | How It Works | Pros | Cons | |----------|-------------|------|------| | Vertical Partitioning | Split by feature (user tables on server A, file tables on server B) | Simple to implement | Doesn't solve scale within one table…

• 10. Caching

  Two levels of caching: | Cache Location | What It Caches | Policy | |----------------|---------------|--------| | Block Storage Cache | Hot/frequently accessed file chunks by content hash | LRU (Least Recently Used) | | Metadata Cache |…

• 11. Load Balancing

  Load balancers placed at two points: | Strategy | How It Works | When To Use | |----------|-------------|-------------| | Round Robin | Distributes requests equally in rotation | Simple default; assumes equal server capacity | | Weighted…

• 12. Security, Permissions & Sharing

  - Encryption in transit: All client-server communication over TLS/HTTPS - Encryption at rest: File chunks encrypted on storage servers (AES-256) - Permission model: Each file/folder has an ACL (Access Control List) stored in metadata DB…

• 13. Failure Handling & Reliability

  | Failure Scenario | Mitigation | |-----------------|------------| | Block server crash | Data replicated across 3+ servers in different zones | | Metadata DB failure | Primary-replica setup with automatic failover | | Client disconnecti…

• Summary Architecture

  ---

• Key Interview Talking Points

  1. Start with requirements — functional + non-functional 2. Chunking is the core insight — enables partial retry, delta sync, deduplication 3. Long polling > polling for real-time notifications 4. ACID matters for concurrent file edits 5…