Design Dropbox/Google Drive - Cloud File Storage

Before selecting storage, I would ask whether you want the file-storage product or the internals of an object store. I will design the product unless you prefer the latter. I will ask the questions that change the design, state assumptions where you want me to proceed, and avoid trying to recreate every feature.

I will support upload/resume, download, named-user sharing and synchronization. I will retain versions for conflict recovery, but defer collaborative editing, previews, global search, public links and cross-user deduplication.

The central invariant is that every published version points to verified, readable content. A successful object upload is not yet a published file. An object ID is never proof of permission.

I use decimal GB/TB/PB unless a binary unit is explicitly written. Assume 10M daily active users, 100M current files averaging 10 MB, and 2M new versions/day averaging 5 MB. These are design inputs. The different average sizes describe stored files versus daily changes.

The byte path dominates transfer capacity, while metadata handles small records. That distinction justifies direct storage transfers before it justifies adding many microservices.

I start with a relational metadata store for atomic version publication, folder changes and ACL updates. Immutable objects hold content. A key-value design could also work, but would require an equally explicit conditional-write and transaction story.

A file, version, manifest and upload session are different entities. In this design logical chunks are separate immutable objects, allowing reuse across versions. They are not S3 multipart parts, which become a single object after completion.

Identity comes from authentication, not a trusted userId in the body. Each operation checks current authorization. I bind an idempotency key to its caller and request digest; reusing the key with different input returns a conflict.

Clients need to distinguish expired sessions, missing content and stale versions. A timeout is an unknown outcome, not permission to blindly create another version.

I can begin with a metadata application, replicated database, object storage and a worker. The control plane authorizes operations; the client moves bulk bytes directly. A durable change log/outbox connects committed metadata to retryable notifications.

A CDN may cache immutable content, but the origin is private and content capabilities expire. I do not need a separate service for every noun to explain a correct baseline.

Let me trace a laptop uploading an edit. The success boundary is the metadata transaction publishing the verified manifest and change event. It is not the final object PUT.

If objects succeed and metadata fails, I temporarily have unreachable objects to collect. That is preferable to publishing a version with missing bytes. The object store and database do not share an atomic transaction.

A push notification only says that something changed. Devices pull the durable change log with a stored cursor after reconnect and periodically as a safety net. A socket cannot guarantee no missed changes.

For downloads, authorize a specific version, verify chunks, assemble a temporary local file and atomically replace the destination. Advance the cursor only after applying or durably journaling the batch.

I partition metadata by owner or shared workspace and keep version changes within the owning partition. I measure hot folders separately from averages. Cross-owner sharing needs explicit authorization relationships; it is not a free distributed transaction.

Fixed-size chunks are simple, but an insertion near the beginning can shift many subsequent boundaries. Content-defined chunking is a deliberate extension with bounded sizes and a versioned algorithm, not something automatically supplied by multipart upload.

I inject faults between transfer, verification, metadata commit and notification. The assertion is one recoverable visible result with no missing or unauthorized bytes. Track oldest upload age, publish failure rate, sync lag, conflict rate, orphan backlog and restore time.

My design uses immutable content, transactional visible versions and a durable change log. Upload, download, sharing and synchronization each have a complete flow. I can go deeper into conflict resolution, object lifecycle or regional recovery.

A senior answer should explain commit/replay boundaries, authorization and offline conflicts. A staff discussion adds ownership migration, hot shared workspaces, measurable recovery objectives and operational validation. More boxes do not replace those guarantees.