What a system design interview measures

01Start with a user outcome

Maya wants to upload an 8 MB photo on her phone and view it later on her laptop. Before drawing servers, decide what the service promises her:

1. Who may read it? Assume only Maya may read the original and thumbnail.
2. When may the phone show “uploaded”? Only after the required file and ownership record are safely saved.
3. Must the thumbnail be ready immediately? Assume it may appear within one minute.
4. Which failures must the original survive? Agree on a specific storage guarantee, such as loss of one storage machine.

These are requirements: statements of what the service must do. The architecture is the explanation of how its parts keep those promises.

An interviewer evaluates whether you can:

• Identify the users and operations before selecting components.
• Explain what one request reads, changes and returns.
• Find a load or failure that could break the proposal.
• Revise the affected operation when a requirement changes.

The first drawing can be small. It needs to explain this upload and read; it does not yet need every possible photo-sharing feature.

02Explain one decision all the way through

Let the phone send the large file directly to private file storage. Keep the photo’s owner and processing status in a database. These details about the file are metadata; they are separate from its image bytes. File storage is often called object storage: it saves bytes under a name. The database makes questions such as “which photos belong to Maya?” practical.

Follow the upload:

1. The application verifies that the caller is Maya. This identity check is authentication.
2. It creates one pending upload record. Call its identifier u17; the phone will use it to refer to this same upload on later requests.
3. It gives Maya short-lived permission to write only the intended file, within the size limit.
4. The phone transfers the file. The application then checks that the expected file finished uploading and belongs to this pending upload.
5. The application changes the saved status from pending to processing. It returns “uploaded” only when the file and ownership record meet the agreed failure protection.
6. A background worker finds saved processing records, creates the corresponding thumbnail and marks that photo ready after checking that the result belongs to this upload. If it crashes, another worker can find the still-processing record and retry the same thumbnail task; the task must not exist only in the first worker’s memory.

Saving data with the agreed failure protection is durability. A database commit completes the database changes under its configured guarantee. A file upload and a separate database commit are not automatically one operation; an unfinished upload needs visible pending status and eventual cleanup.

Now lose the confirmation response after step 5. The phone repeats confirmation for u17. The application must find that existing record and return its saved outcome rather than insert another photo. If the status is still pending, change it only through a database operation that checks and updates the status together. Simultaneous confirmations cannot both create new records. Keeping the intended result unchanged on repetition is idempotency.

03Choose depth and communicate uncertainty

For a read, checking identity is only the start:

1. The application identifies the caller.
2. It reads the photo’s saved ownership and status.
3. It checks that this caller may read this photo. This permission check is authorization.
4. Only then does it return the permitted original or thumbnail.

Explain a design choice by connecting its saved work and added work:

• Direct file upload saves the application from carrying every 8 MB file. It adds completion checks and abandoned-upload cleanup.
• Delayed thumbnail creation makes uploads finish sooner. It needs saved processing status so a worker can resume after a crash.
• Cached file copies can reduce repeated reads. They must still obey the required permission rules.

If the prompt changes to popular public photos, revisit bytes delivered per view, repeated access to one photo and delivery capacity. Privacy remains relevant wherever content is still private.

Close with evidence, not component names:

• Repeat confirmation after losing its response and verify that one photo exists.
• Request the photo from another account and verify that no private bytes are returned.
• Leave an upload unfinished and explain when its record and file are removed.

If you do not know a database feature, state the required behavior first: “Check pending status and save processing status together.” Verify the product’s way to do that instead of assuming separate reads and writes are safe.