Detailed Component Design

files are split into blocks of 4mb on upload and then each block gets a hash value, is then encrypted and stored in cloud storage. on editing a file, we compute the hash values and check against the stored ones, if we find different values then we update only those blocks and write in cloud the updates. cold storage will store the least used files and file versions so it wont occupy too much memory in cloud storage (which needs to be as fast as possible for retrieval/writes)

flow for resuming a download/upload - we make a call to fetch the url from server side and then we check the file status, if it is still uploading or downloading in progress, then we can resume it by checking the missing blocks and continuing to upload/ download the missing ones.

on system failures:

if a load balancer fails, another available one will take its place;

block server failure - other server will pick it up

cloud storage: s3 failure, a new s3 instance will pick it up, either from same region, or if a region is down then from a near region;

api server - they are stateless so a new api server instance can pick it up

metadata cache failure - metadata cache is replicated multiple times so a replica can pick it up

metadata db failure - if master is down then a slave will be prompoted, if a slave is down then a new instance will take its place

notification service failure - a new instance will start picking up from the ongoing requests

offline backup queue failure - if one queue fails then subscribers might need to resubscribe to a new one

conflicts handling: if 2 users edit the same file, then the first one that saves the update will work normally and will be let through but the second one will be anounced that there s a conflict that they must fix

A background job runs every hour to clean up orphaned data:

Stale upload sessions:

Sessions older than 24 hours with status "in_progress" are marked expired
Associated chunks in temporary storage are deleted
Upload record moved to "failed" state

Unattached chunks:

Chunks not linked to any file record after 48 hours are deleted
Identified by scanning temporary storage and cross-referencing with metadata DB

Soft delete cleanup:

Files in trash older than 30 days are permanently deleted
Blocks with zero references (no file versions point to them) are purged weekly

Background integrity checker runs continuously at low priority:

Detection:

Scans storage blocks on a rolling basis (full scan every 30 days)
Recomputes hash for each block, compares against stored hash
Corrupted blocks flagged for repair

Repair:

Corrupted blocks restored from replica in different AZ
If all replicas corrupted, restore from backup
Alert triggered if repair fails

Prevention:

All blocks stored with 3x replication across availability zones
S3 automatically verifies checksums on read/write
Annual full integrity audit with report

All file transfers use HTTPS with TLS 1.3. Presigned URLs enforce TLS—requests over HTTP are rejected. Client SDKs validate certificates and refuse downgrade attacks. Internal service-to-service communication uses mTLS with certificate rotation every 90 days.

Files with >100 downloads/day are pushed to CDN edge nodes. Public files cached with 24-hour TTL, shared files with 1-hour TTL. On file update, CDN cache is purged immediately. Popular files pre-warmed to all regions. Origin protected by rate limiting (max 1000 req/sec per file) with regional CDN nodes acting as shield.

When DB connection pool exceeds 80%, new requests receive 503 with Retry-After header. Read traffic shifts to replicas, writes buffer in Redis (max 60 seconds). Automated failover promotes replica within 30 seconds. Buffered writes replay after failover. If DB unavailable longer, system enters read-only mode—downloads work, uploads pause until recovery.

Single region: RPO 1 hour (hourly backups), RTO 4 hours (restore + replay logs).

Multi-region: RPO <1 minute (sync replication), RTO <5 minutes (DNS failover).

Backup tiers: hot (real-time 3-AZ replication), warm (hourly cross-region snapshots), cold (daily glacier backups retained 1 year). Quarterly DR drills verify RTO targets.

Every file save creates a new version. Each version is immutable and stored with:

Version ID (incrementing integer)
Timestamp
User who made the change
Hash of all blocks
Pointer to block list (reuses unchanged blocks from previous version)

Version retention:

Last 100 versions kept in hot storage
Versions older than 30 days moved to cold storage
Deleted versions retained 30 days before permanent purge
Users can restore any previous version via POST /files/{fileId}/restore/{versionId}

Storage efficiency:

Only changed blocks stored per version (deduplication)
If 1 block of 10 changes, new version stores 1 new block + 9 pointers to existing blocks

Submissions

Displaying Solutions with Scores Ranging from 1 to 10