A practical system design template

01Use a template of questions, not components

An owner saves a private text snippet and names the readers allowed to open it. Later, the owner can remove a reader. Use this paste service to make the interview template concrete.

Assume snippets are at most 100 KB. Simultaneous live editing is outside the exercise. Work through seven outputs:

1. Requirements: Specify creation, authorized reading and reader removal. State how quickly a removed reader must lose access.
2. Estimates: Calculate the creates, reads and bytes that could affect storage or response time.
3. API: Give the inputs and results for create, read and revoke operations, including errors and repeated requests.
4. Data model: Save the text, owner, reader grants and creation-request result. A grant records which reader may open which paste.
5. First design: Show how one database can save this small paste and its permissions, then trace a read.
6. Deep dive: Explain a risk such as a lost creation response or two simultaneous permission edits.
7. Failure review: Revoke a reader while text remains cached, lose a response and make the permission store unavailable.

An API describes what callers send and observe. A data model describes the saved records that make those operations possible. Keeping them separate prevents a list of endpoint names from hiding missing permission or retry data.

Change the example if an assumption changes:

• An anonymous public link allows readers without named-account grants. The service must still check that the paste is active and unexpired before returning its text.
• Multi-gigabyte content may justify separate file storage and upload completion handling.
• Live editing requires a collaboration and conflict-handling mechanism; storing text alone does not supply it.

02Fill the contract and trace a small baseline

First estimate the assumed creation workload:

1. One hundred thousand users ×2 snippets/day =200,000 creates/day.
2. Divide by 86,400 to obtain about 2.3 creates/second on average.
3. Multiply 200,000 by 10 KB/snippet to obtain 2 GB/day before copies and supporting storage.

These inputs justify starting with a small design and measuring its complete queries. They do not prove one machine’s capacity.

For creation, let r9 name the owner’s intended request and p31 name the resulting paste:

1. Verify the owner and validate the size and reader list.
2. In a database transaction, check whether this owner’s r9 already has a saved result.
3. For a matching repeat, return the original p31. Reject reuse with different text or readers.
4. For a new request, save the text, owner, grants and r9 result together. Enforce request-identifier uniqueness in the database so simultaneous repeats cannot create two pastes.
5. Commit and return p31 with its version. Reject oversized text before creating the paste.

For a read by Eli:

1. Identify Eli and find p31.
2. Check that the paste is active and has not expired.
3. Read the paste’s saved grant for Eli and check that it still permits reading; a prior successful read or a cached text copy is not a grant.
4. Return text only if those checks pass. In this example, a caller without permission receives the same not-found response as for an absent paste, so the reply does not reveal that a private paste exists.

A text cache can save a repeated content lookup, but the cached text does not prove that Eli’s grant still exists. One transactional database can keep modest text and grants together. If content later moves to a file store, represent unfinished creation explicitly because uploading the file and saving the record can fail separately.

03Deepen only where the promise needs it

Two owner devices can edit the reader list at the same time. Explain the update rather than saying “handle consistency”:

1. Each device reads grant version 4 and proposes a different edit.
2. An update asks the database to change the grants only if their saved version is still 4.
3. The database checks that condition and saves the new grants and version 5 together.
4. A later update based on 4 fails with a conflict. Its device rereads 5 and decides whether to apply a new edit; it does not silently overwrite the first.

Compare storage choices under the same requirements:

• Keeping small text and grants in one database makes all-or-nothing creation simpler.
• Moving large text or files out of that database can reduce byte-handling work, but requires pending creation, confirmation and cleanup.
• Adding a cache helps only if repeated reads save enough work and the permission policy remains enforceable.

Then test the concrete failures:

1. Lose creation’s response. A repeated r9 must retrieve p31.
2. Remove Eli’s grant while text stays cached. The next protected read must obey the agreed revocation rule.
3. Race two grant edits from version 4. One must detect the changed version instead of silently overwriting it.
4. Disconnect the permission store. Wait or refuse the protected read as agreed; do not infer permission from cached text.

The template is complete for the agreed scope when these operations have working steps, stated limits and checks. End with the current design, its largest unresolved risk and the evidence needed before the next change.