Media & storage: code and config reading
Read real upload handlers, storage configs, sync logic, and counters, then pick the senior fix: a direct-to-object-store upload, an erasure-coding overhead calc, a delta-sync chunk comparison, and an eventually-consistent view counter.
Media bugs hide in the handler and the config: a request that buffers gigabytes, a replication factor, a chunk comparison, a synchronous counter. Read each snippet, find the design flaw, and pick the change a senior engineer would commit.
Practise the design-review loop: locate where bytes touch the app path, where redundancy is mis-chosen, where sync moves too much, and where a counter is dangerously synchronous.
Snippet 1 — the upload handler
@app.post("/upload")
def upload(req):
data = req.body.read() # the whole video, in memory
db.execute("INSERT INTO videos (id, blob) VALUES (?, ?)", req.id, data)
return {"ok": True}What's wrong with this upload handler, and what's the fix?
Snippet 2 — the storage config
# object store durability config
redundancy: replication
replication_factor: 3 # 3 full copies of every object
# workload: exabytes of cold archival video, rarely readFor exabytes of cold, rarely-read archival video, what does this config cost, and what's the better scheme?
Snippet 3 — the sync diff
def sync_changes(local_file, remote_version):
local_chunks = [sha256(c) for c in chunk(local_file)]
remote_chunks = remote_version.chunk_hashes
to_upload = [h for h in local_chunks if h not in set(remote_chunks)]
upload(to_upload) # then commit a new version listing local_chunksA user appends a paragraph to a 200 MB file (~50 chunks). Roughly what does this upload, and what does it demonstrate?
Snippet 4 — the view counter
def record_view(video_id):
db.execute(
"UPDATE videos SET views = views + 1 WHERE id = ?", video_id
) # one synchronous UPDATE per view
# a viral video draws ~200,000 views/secondAt ~200,000 views/second on a viral video, what does this counter do, and what's the right design?
- 01How do you spot a bytes-on-the-data-path bug in an upload handler, and the fix?
- 02Given a 3× replication config for cold data and a synchronous per-view counter, what do you change and why?
Every media decision in this unit shows up in code you can read. The upload handler that reads the whole body and writes a DB blob is the bytes-on-the-data-path bug — fix it with a presigned URL so the client uploads directly to object storage and the DB holds only a metadata reference. The 3× replication config for cold archival data wastes 200% overhead — switch cold data to erasure coding (10+4 ≈ 1.4×, 4-loss tolerance) while keeping replication for small hot objects. The sync diff that compares chunk hashes uploads only the new-hash chunks (~4–8 MB for a one-paragraph append), the essence of delta sync and where cross-version dedup falls out free. And the synchronous per-view UPDATE is a hot row that collapses under viral load — make the count eventually consistent by logging events and aggregating asynchronously. The senior habit is the same across all four: find where bytes or consistency are being handled wrong, and pick the fix that respects the structure rather than papering over it.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.