Dropbox / File Storage — system design by AgileViper46

Scalability target is too vague for the stated assumptions

You mention 'scalability for 10M DAU', but what happens when those 10M users are active during peak sync windows? The NFR section does not translate the assumptions into concrete throughput or concurrency targets for uploads, downloads, sync fanout, or metadata reads/writes. Without peak numbers, it is hard to judge whether the 2-second sync goal is realistic under load. You could improve this by stating expected peak QPS, concurrent uploads, and event fanout volume derived from the 10M DAU assumption.

Consistency model is only partially justified

You say eventual consistency is acceptable between devices and users, but have you considered which operations cannot tolerate stale reads? For example, what happens if a user changes sharing permissions or rolls back a file version and another device still sees stale metadata from a replica? The design should separate 'eventual consistency is fine for sync propagation' from cases where stronger consistency may be needed for permission checks, version visibility, or rollback correctness.

Availability and durability lack measurable targets

The NFRs identify availability and durability, but what happens when a storage zone fails or metadata DB is unavailable? Without concrete targets such as uptime objectives or durability expectations, these requirements do not strongly drive design decisions. You could improve this by defining explicit goals like service availability and expected data loss tolerance, then showing how the chosen mechanisms satisfy them.

Chunk-level entity is implied but not modeled

Have you considered what happens when sync and resumable upload need to reason about which chunks already exist, which chunks belong to which version, and which partial uploads can be cleaned up? The explanation relies heavily on chunk hashes, chunk completion, and chunk reuse, but there is no explicit chunk/chunk-mapping entity in the core model. Without that relationship, the happy path for dedup, resume, and garbage collection is underspecified. A Chunk entity plus a FileVersion-to-Chunk mapping would make these flows much clearer.

File vs FileMetadata relationship is not clearly defined

What happens when you need to answer basic questions like 'what is the current version of this file?', 'who owns it?', or 'which metadata is immutable per version versus mutable at the file level'? Right now File and FileMetadata are both listed, but their boundary is unclear. If FileMetadata is just attributes of File, splitting them adds ambiguity; if it represents per-version metadata, that should be tied explicitly to FileVersion. Clarifying whether this is 1:1 with File or 1:N across versions would avoid confusion in the core model.

Sharing relationships are only partially expressed

Have you considered how permissions compose when multiple users can edit and reshare a file? The explanation says owner or editors can add/remove users, but the entity model only lists Share without defining the relationship shape. For this feature, you want the model to clearly express that a File can have many Share entries, each connecting a file to a target user with a permission level. Otherwise the access-control path is left implicit rather than modeled.

User scale never gets translated into traffic

You state 10M DAU and 1B files, but what happens at peak upload/download/sync time? Without even rough QPS or peak concurrency estimates, it is hard to tell whether the file service, sync path, database, and blob-store interactions can handle the expected load. A stronger answer would convert DAU into daily uploads/downloads, then into peak API QPS, chunk request rates, and concurrent connections.

Storage planning stops at metadata and ignores the dominant data volume

Have you considered the actual blob storage footprint? With 1B files at 10MB average, raw file data is on the order of exabytes, and version retention for 30 days can materially increase that depending on update frequency and chunk reuse. Without sizing the object store, replication overhead, and growth rate, the capacity plan is incomplete for this problem.

The metadata estimate is not connected to the stated assumptions

What happens if the average file size is really 10MB as given, but the calculation later assumes 100MB and 20 chunks per file? That breaks the chain from assumptions to infrastructure. The exact numbers do not need to be perfect, but the methodology should stay internally consistent so the resulting database and chunk-table sizing is trustworthy.

Single-Postgres conclusion is not justified by throughput or operational load

You conclude that ~2TB of metadata can fit in a single Postgres instance, but what happens when 10M DAU generate uploads, version writes, share updates, sync polling, and chunk-completion updates concurrently? Capacity is not just about bytes at rest; it is also about write amplification, index size, hot rows, and read/write throughput. You should justify the database choice with expected request rates, not only storage size.

Core download, sync, and rollback APIs are not actually defined

How does a client download a file, fetch version history, roll back to a prior version, or ask 'what changed since my last sync'? The explanation mentions these flows, but the route list does not expose concrete endpoints for them. Without APIs for download URL generation, version listing, rollback, and change polling, the core functional requirements cannot be exercised cleanly by a client.

Chunk upload protocol is underspecified

You mention chunked upload, per-chunk completion, and server-side verification, but the API surface only shows POST /files and PUT /presignedUrl. What happens when chunk 17 of 200 fails, the client retries, or the client reconnects after losing state? At this scale, clients need explicit APIs or message contracts for initiating multipart upload, listing pending chunks, marking chunk completion idempotently, finalizing the upload, and resuming interrupted uploads.

Resource design is inconsistent and hard to reason about

The routes mix resource-oriented paths and action-like paths in a way that makes ownership unclear: POST /files, PUT /files/:id, PUT /presignedUrl, POST /files/:id/share, PUT /files/share. What is the resource behind PUT /files/share, and which file does it modify? A cleaner shape would make file versions, shares, and upload sessions explicit resources so clients can understand what they are creating or updating.

HTTP verb semantics are muddy for create-vs-update flows

What happens when a client calls PUT /files/:id? Is that replacing metadata, uploading a new version, or resuming an incomplete upload? For file storage systems, creating a new version is usually a distinct operation from updating metadata. Overloading one PUT route for multiple meanings makes retries and client behavior ambiguous.

No API for listing versions or shared files, so pagination concerns are unaddressed

A user may have many files, many shared items, and many versions within the 30-day retention window. If you add the necessary list endpoints, what happens when a folder or account has thousands of items? At this scale, clients need paginated list APIs, ideally cursor-based, for files, shares, versions, and sync changes.

Error model and retry guidance are missing

What does the client see when permission checks fail, a presigned URL expires mid-upload, a chunk hash does not match, or finalization happens before all chunks are durable? Returning just OK/ERROR is too vague for a sync client. The API should define status codes and structured errors so clients know when to retry, refresh a URL, restart a chunk, or surface a permanent failure.

Redis pub/sub is fragile for sync fanout

Have you considered what happens if the Sync service is disconnected or restarted while Redis pub/sub messages are being published? Native pub/sub is lossy and does not retain events, so clients can miss updates and rely entirely on polling. For a core sync feature, a durable stream or queue would be safer for server-side consumption, with Redis used only for transient fanout if needed.

Single points of failure are only partially addressed

What happens when the File service instance, Sync service instance, Redis node, Kafka broker, or cleanup worker dies? The design mentions API gateway/load balancer and a Postgres read replica, but HA is not described for the rest of the critical path. Read replicas help reads, but they do not remove the single writer failure risk. You should call out multi-instance stateless services behind the LB and managed HA setups for Redis/Kafka/Postgres failover.

Upload completion flow is split across client callbacks and blob events

Have you considered what happens if the client says a chunk upload completed but the blob event is delayed, duplicated, or never arrives? Right now chunk state seems to depend on both client-side marking and asynchronous storage notifications, which can diverge. A clearer source of truth is needed: either finalize from storage-side completion only, or make the client call a complete-upload API that verifies all expected parts exist before committing the version.

Sync service connection model is underspecified for multi-device scale

What happens when millions of clients maintain long-lived SSE connections for near-real-time sync? The design names a Sync service but does not explain how connections are partitioned, how file-to-subscriber mappings are stored, or how fanout is distributed across instances. Without that, the Sync service itself may become the next bottleneck. You could improve this by describing horizontal scaling of connection servers and how subscriptions are routed or rebalanced.