Design an image upload service

Question 1

Who is uploading?

Accepted Answer

The uploader is where the 3MB starts, and where the wait would be felt if the design made it wait.

Question 2

What receives the upload?

Accepted Answer

Something has to accept the bytes, check the file is really an image, and decide where it goes. That is a service.

Question 3

Where do the image files go?

Accepted Answer

Image bytes in a database make backups enormous and replication slow, and on a service disk they vanish when the instance does. Object storage is built for large files that never change, and it is the right answer here almost every time.

Question 4

Resizing a 3MB photo twice takes a few seconds. Does the upload wait for it?

Accepted Answer

It should not. Store the original, put a job on a queue, and return straight away — the thumbnail appears a moment later. Doing the resize inside the request makes every upload slow and makes a burst of uploads an outage.

Question 5

How do you know which sizes exist for an image, and who owns it?

Accepted Answer

The bytes live in object storage; everything you need to query — owner, dimensions, which sizes are ready — is small and structured, and belongs in a database.

Question 6

How many uploads a second is 10M a day?

Accepted Answer

10,000,000 / 86,400 is about 120 a second. At 3MB each that is around 360 MB/s arriving — which is the number that rules out keeping any of it on the service itself.

Blueprint — system design