1. Consideration

In my imagine, file share system should be heavy read system. Normally user would upload some files, then download (accessed) by other users many times.

And managing file storage system could be tricky when considering throughput, fault tolerance and performance. So it would be better to rely on third party solutions.

2. System Assumption

Based on Brad Lee reply on system traffic

let’s say this app is just about to launch and does not expect high traffic, but you can keep the flexibility for the high traffic and note in the document, we would love to see that

I would try start simple and maintain some flexibility for future traffic.

Some other imagination beyond the scope

1. File storage size could go insane if we don’t set expiration time. I think there are few limitation strategies that we can choose

   • total file storage size. Such as google drive.
   • total file amount
   • expiration time on every file. In Alfred Camera we chose this.

   For file share system, I think first strategy would be nice. Let user choose which file to keep.

3. Architecture

I would run application on cloud. I choose AWS as the main platform due to my personal experience. It’s stable, cost reasonable and providing many functionality.

Here is overall architecture

• Every box is a component. Box with dotted line is not implemented in this quiz.

3-1. Upload File

There are two critical technical decisions.

1. Upload file

For upload file, I don’t want to store file or transfer file through application server. Because uploading file consumes time and bandwidth.

I would return presigned url and let client upload file by presigned url. At this stage, I could set the limit of file size (if we want to limit) and specify the file path for client. The file would be stored in private bucket because default privacy is not public.

Then client could upload file to AWS S3 directly, S3 could notify server when file is uploaded successfully by lambda.