Interview Perspective

Strong answer direction: confirm VOD (not live), confirm upload is in scope, clarify public/private support, confirm whether global distribution and search are in scope, and explicitly set DRM/recommendations/ads/moderation-internals as out of scope. What interviewer tests: whether you can bound an intentionally huge problem instead of trying to design everything. Read deeper: Problem Definition.

• What if the interviewer says 'assume live streaming is also in scope'? — State clearly that live streaming has fundamentally different latency and delivery requirements (low-latency chunking, different packaging) and is genuinely out of scope for this module's mental model — flag it rather than improvising an answer that conflates VOD and live mechanics.

Strong answer direction: state the formulas (upload ingress, processing work, playback egress, storage) rather than memorized figures, and note that views typically outnumber uploads by a large margin for this kind of product — framed as an assumption, not a fact. Use that ratio to justify why upload/processing and delivery get different architectural treatment. What interviewer tests: whether your numbers actually inform your design choices, and whether you're honest about them being assumptions. Read deeper: Scale Estimation.

Strong answer direction: no, not by itself — segmentation mostly reorganizes a rendition's bytes into many small files. What actually multiplies storage is producing additional renditions, bitrates, or codecs, since each is an independently-encoded copy of the source. What interviewer tests: whether you actually understand the mechanics behind your own storage estimate rather than reciting a number.

Strong answer direction: a single-request upload of a multi-gigabyte file has no recovery story if the connection drops; splitting into independently-retriable parts fixes that. Routing bytes through the app tier wastes app-server bandwidth/connections on pure data transfer that has nothing to do with business logic — a scoped, short-lived credential lets the client upload directly to object storage instead. What interviewer tests: whether you can justify both decisions independently rather than bundling them as one vague 'best practice.' Read deeper: Upload Architecture.

Strong answer direction: the server verifies against the object store's own authoritative multipart/session state at finalize time — the client's claim that every chunk arrived is a hint, not proof. What interviewer tests: whether you'll trust client-reported state for something correctness-critical. Read deeper: Upload Finalization.

• What if the client claims completion but a part is actually missing? — Finalize verification catches this and rejects/repairs before the object is ever treated as durable — it should never silently proceed based on the client's word alone.

Strong answer direction: finalize must be idempotent — a retried call for the same upload_id discovers the already-finalized result and returns it, rather than creating a duplicate video record or scheduling a second processing workflow. What interviewer tests: whether you've thought about response-loss as a distinct failure mode from request-loss. Read deeper: Finalize Response Lost.

Strong answer direction: sessions expire on a timer; expiry triggers cleanup of unfinished multipart uploads, temporary objects, and the stale session record — otherwise abandoned attempts quietly accumulate storage cost forever. What interviewer tests: whether you think about the unhappy path's resource lifecycle, not just the happy path. Read deeper: Upload Session.

Strong answer direction: at real upload volume/size, that bandwidth cost is exactly what direct-to-storage upload avoids; validation that needs to happen can happen at finalize or asynchronously afterward instead of inline during transfer. What interviewer tests: whether you understand the trade-off is deliberate, not an oversight. Read deeper: Trade-offs & Decisions -> Application Server vs. Direct Upload.

Strong answer direction: transcoding is CPU-intensive and duration-variable, which shouldn't share a request/response path with anything latency-sensitive. The fast acknowledgement means the upload was accepted and durably finalized — not that the video is fully processed and ready to stream; those are different milestones tracked by different states. What interviewer tests: whether you conflate 'upload accepted' with 'video ready.' Read deeper: Trade-offs & Decisions -> Sync vs. Async Processing.

Strong answer direction: a transactional outbox / durable job record — write the job row in the same transaction as the finalize write, then have a separate dispatcher publish it, retrying until the queue acknowledges. This turns an unrecoverable dual-write gap into a bounded dispatch-lag problem. What interviewer tests: whether you recognize 'write to DB, then publish to queue' is not automatically atomic. Read deeper: Durable Processing Handoff.

Strong answer direction: this is an expected consequence of at-least-once delivery/lease expiry, and it's made safe by construction — each attempt writes to its own attempt-specific staging keys, and only one validated attempt's output is ever published as the active version. What interviewer tests: whether your retry story actually prevents corruption, or just hopes duplicates won't happen. Read deeper: Duplicate Processing Job and Safe Output Publication.

• What if a worker's lease expires but it's actually still alive and finishes later? — Same mechanism handles it — see Worker Times Out but Keeps Running.

Strong answer direction: publication is a distinct, final gate — no processing stage exposes its output directly; only a validated, complete artifact set gets its manifest published and its active-version pointer switched atomically. What interviewer tests: whether you separate 'processing produced something' from 'it's safe to show viewers.' Read deeper: Safe Output Publication.

Strong answer direction: based on the source's own quality (never upscale to fill a rung), the device/network population being served, codec support, content characteristics, and cost — not a fixed universal list. What interviewer tests: whether you present the ladder as a product/cost decision instead of a memorized constant. Read deeper: Transcoding & Rendition Ladder.

Strong answer direction: per-representation state tracking means the other renditions aren't affected; whether to publish a reduced ladder or treat this as an overall failure requiring a mandatory minimum set is an explicit product policy decision, not something to leave implicit. What interviewer tests: whether you've thought about partial success as a first-class outcome. Read deeper: One Rendition Fails.

Strong answer direction: no — queue depth alone doesn't distinguish a backlog of many small clips from a few very expensive 4K jobs. Track oldest job age, queued media minutes, and SLO attainment instead. What interviewer tests: whether you understand backlog as a work-weighted quantity, not a job count. Read deeper: Processing Backpressure.

Strong answer direction: codec is the compression algorithm (H.264/AVC, H.265/HEVC, AV1, VP9); container/package format is the file structure wrapping the encoded streams (MP4, fMP4, TS); resolution is pixel dimensions; bitrate is bits-per-second target. They're independent axes — the same resolution can exist at different bitrates or in different codecs. What interviewer tests: whether 'rendition' is a real, structured concept for you or just a synonym for 'resolution.' Read deeper: Codec, Container, Bitrate & Resolution.

Strong answer direction: viewer devices and networks vary enormously; a single fixed quality either stalls on weak connections or wastes bandwidth on strong ones. Multiple renditions plus ABR let the player match quality to actual conditions. What interviewer tests: whether you connect the rendition ladder back to the actual viewer-diversity requirement.

Strong answer direction: without compatible segment and keyframe boundaries across renditions, switching mid-stream can require re-buffering or produce a visible glitch — arbitrary independent cuts don't guarantee a clean switch. What interviewer tests: whether you understand alignment as a packaging discipline, not an incidental detail. Read deeper: Segment Alignment.

Strong answer direction: at a high level, both involve a master manifest listing available representations and per-representation media playlists/manifests listing segment URLs — the protocol-level bytes don't matter for this conversation, the manifest/segment/versioning concepts do. What interviewer tests: whether you can operate at the right altitude instead of going into codec/protocol internals nobody asked for. Read deeper: Manifest & Packaging.

Strong answer direction: a long-lived CDN cache key pointing at bytes that can change in place risks serving inconsistent content to different viewers/edges; immutable versioned objects make aggressive, long-TTL caching safe and make rollback to a prior version simple. What interviewer tests: whether you connect the media-storage decision to the CDN-caching decision, rather than treating them as unrelated. Read deeper: Trade-offs & Decisions -> Mutable vs. Versioned Media Objects.

Strong answer direction: it combines an estimate of recent achieved throughput, current buffer occupancy, and device/display constraints to choose the representation for the next segment — biasing toward avoiding a stall over maximizing quality. What interviewer tests: whether you can name the actual signals instead of saying 'it picks the best quality' vaguely. Read deeper: Adaptive Bitrate Player.

Strong answer direction: not necessarily — a startup heuristic may choose a higher, conservative representation if early signals (or a fast known connection) suggest it's sustainable; the goal is minimizing time-to-first-frame while avoiding an immediate rebuffer, not mechanically picking the lowest rung. What interviewer tests: whether you'll correct a common but inaccurate absolute claim rather than repeat it.

Strong answer direction: decompose it — metadata/authorization request, manifest fetch, connection setup where applicable, first-segment fetch, decode/first-frame render. Optimize whichever step measurement shows is actually slow; they look identical to a user but need different fixes. What interviewer tests: whether you can break down a fuzzy metric into actionable components. Read deeper: Playback Startup Latency.

Strong answer direction: the player detects the sharp throughput drop and proactively requests a lower sustainable representation for subsequent segments rather than waiting for the buffer to fully drain and stall. What interviewer tests: whether you understand ABR as anticipatory, not purely reactive to an already-empty buffer. Read deeper: Bandwidth Collapse.

Strong answer direction: smoothing/hysteresis — require a sustained trend before switching, and weight buffer health over instantaneous throughput noise, rather than reacting to every small fluctuation. What interviewer tests: awareness that naive ABR logic can itself create a bad experience. Read deeper: ABR Oscillation.

Strong answer direction: the player maps the target timestamp to the corresponding segment(s) in the current representation's manifest and requests those directly — no need to download or re-download everything before the seek point. What interviewer tests: whether you connect segmentation's benefits concretely to seek behavior, not just buffering.

Strong answer direction: with viewers spread globally and views vastly outnumbering uploads (as an illustrative assumption), serving everyone from one origin concentrates unsustainable bandwidth/request load in one place and adds latency for distant viewers. A CDN caches popular content near viewers, turning a global load problem into a mostly-local one. What interviewer tests: whether you tie the CDN back to the scale numbers you established earlier. Read deeper: Delivery & CDN.

Strong answer direction: an edge miss is one specific edge not having the object; an origin shield is an intermediate tier that collapses many edges' misses into far fewer requests reaching origin — without it, a viral video's cold start hits origin once per missing edge, not once per object. What interviewer tests: whether you understand cross-edge miss amplification as a distinct problem from a single edge's cache-miss rate. Read deeper: CDN Cache Hierarchy.

Strong answer direction: reroute to an alternate healthy edge/PoP where routing supports it; do not treat unrestricted direct-to-origin as the automatic safe fallback — a large platform's origin can be overwhelmed by traffic that size. A broader provider outage may warrant an alternate CDN or a controlled, rate-limited degraded mode, not an unbounded failover. What interviewer tests: whether you'll correct the common but unsafe assumption that origin fallback is always fine. Read deeper: CDN Edge Failure and CDN Provider Outage.

Strong answer direction: conceptually video/version + representation + segment for segments (safe as a long-TTL key since segments are immutable once published); manifests may need different versioning treatment. If a signed authorization query parameter is naively included in the cache key, every viewer gets a unique key for the same object and the hit ratio collapses. What interviewer tests: whether you connect cache-key design to both efficiency and correctness (not leaking access across users). Read deeper: CDN Cache Key.

Strong answer direction: at real global viewer scale this concentrates bandwidth and adds latency in a way a single origin (or even several regional origins) can't absorb — the CDN is what makes hot/viral videos survivable rather than catastrophic for origin. What interviewer tests: whether you can justify the CDN as load-bearing rather than an assumed default.

Strong answer direction: a metadata/authorization service decides entitlement, then issues a short-lived signed credential (URL/cookie/token) that the CDN/origin actually require and validate before serving manifest/segments — the metadata check alone is not enough if the delivery layer will serve anyone who has or guesses a URL. What interviewer tests: whether you connect the 'private' flag in metadata to an actual delivery-layer enforcement mechanism. Read deeper: Playback Authorization.

Strong answer direction: stop issuing new authorization immediately, update metadata/visibility, remove from search/discovery, and invalidate or bound the validity of already-issued cached access according to the delivery design — the fact that credentials are already short-lived limits how long any exposure window can stay open. What interviewer tests: whether you can sequence a multi-system propagation correctly, not just name the individual systems. Read deeper: Metadata Cache Stale Privacy.

Strong answer direction: a cache's job is to serve bytes quickly and repeatedly by design — if it silently continues serving a cached copy after access should have been revoked, or if a cache key strips the authorization parameter without the origin still enforcing it, the cache has effectively overridden the authorization decision. Authorization has to be enforced at (or on the way to) delivery, not assumed away by caching convenience. What interviewer tests: whether you see the tension between 'cache aggressively' and 'enforce access precisely' and can reconcile it. Read deeper: CDN Cache Key.

Strong answer direction: a relational database is built for structured rows/transactions, not multi-gigabyte binaries; object storage is built for the reverse. The metadata store holds pointers/references to the actual media objects. What interviewer tests: a clean, quick justification for a foundational decision you'll reference all interview. Read deeper: Object Storage.

Strong answer direction: only after the processing DAG completes, outputs are validated, and the publication boundary atomically switches the active-version pointer — a metadata row existing is not sufficient by itself; 'ready' (validated artifact set exists) and 'published/visible' (policy permits discovery/playback) are also separable states. What interviewer tests: whether you understand metadata lifecycle as several distinct questions, not one flag. Read deeper: Metadata Lifecycle.

Strong answer direction: search indexing lags metadata changes by design for ordinary edits, but deletion/privacy-restricting changes deserve materially higher-urgency propagation than routine ranking freshness — and regardless, playback authorization is the actual final gate, so a stale search entry shouldn't itself grant access. What interviewer tests: whether you distinguish a discoverability bug from an access-control bug. Read deeper: Search Index Stale Delete.

Strong answer direction: the reprocess produces a new version (v2) in its own staging area while v1 remains the active, playable version; only once v2 validates does metadata switch the active-version pointer, and v1 can be garbage-collected afterward. What interviewer tests: whether you connect reprocessing back to the same safe-publication mechanism used for the original processing. Read deeper: Safe Output Publication.

Strong answer direction: there's no universal technical definition — it's product policy, illustratively something like 'crosses a defined watch threshold.' State that the specific threshold is configurable, not a hard-coded engineering fact. What interviewer tests: whether you'll invent a fake universal rule under pressure instead of correctly framing it as a product decision. Read deeper: View Event Semantics.

Strong answer direction: a synchronous per-view increment creates severe write contention on one row for any popular video; asynchronous aggregation batches many increments into periodic writes, trading a small display lag for removing a hot-row bottleneck. What interviewer tests: the classic eventual-consistency trade-off reasoning. Read deeper: View Counting.

Strong answer direction: duplicates are suppressed via a stable event identity within a bounded dedupe window; lost events are an accepted, bounded approximation for a user-facing display counter, assuming the product doesn't require exactness here. What interviewer tests: whether you'll overstate the guarantee — bounded dedupe is not the same as an exact lifetime count. Read deeper: View Event Duplicate and View Event Loss.

Strong answer direction: shard or hierarchically aggregate that specific key — local partial aggregates merged later, or dynamic re-partitioning — rather than letting one reducer absorb the entire viral video's event volume. What interviewer tests: whether you can extend the general hot-key pattern to this specific pipeline. Read deeper: Hot View Counter.

Strong answer direction: approximate, by design, for the user-facing display count — and that's an acceptable, deliberate trade. Anything with financial/contractual stakes (billing, revenue-sharing) would need a fundamentally stricter, separately-designed guarantee, which is out of scope here. What interviewer tests: whether you can draw the line between 'good enough for a popularity signal' and 'not good enough for money.' Read deeper: Trade-offs & Decisions -> Exact vs. Approximate View Count.

Strong answer direction: a CDN solves delivery latency and origin-traffic reduction for cached content — it doesn't replicate the origin, the processing pipeline, or the metadata database. Origin availability, upload locality for distant creators, and disaster recovery require actual regional origin infrastructure, which is a genuinely separate decision. What interviewer tests: precisely this conflation — be ready to draw the line clearly. Read deeper: Multi-Region Architecture.

Strong answer direction: each video/partition has one authoritative write-owner region at a time; other regions read from asynchronously replicated copies. A network partition must not let two regions independently accept conflicting writes — failover to a new authoritative writer happens only after an explicit fencing/ownership decision. What interviewer tests: whether you'll casually accept 'both regions can write' as fine. Read deeper: Multi-Region Ownership and Region Partition / Split-Brain.

Strong answer direction: don't promise seamless failover — a multipart upload session is generally tied to the region/storage session it was created in, so a mid-upload regional failure likely requires the client to restart the upload against another region, unless the architecture explicitly built cross-region upload session portability. What interviewer tests: whether you'll overpromise continuity that isn't actually designed in. Read deeper: Regional Failure.

Strong answer direction: this is a direct consequence of selective (not universal) replication — the request either needs to be routed to a region that does hold the object, at higher latency, or the platform accepts real unavailability for that specific case; failing over to a region without the data doesn't fix anything. What interviewer tests: whether you connect the replication-policy trade-off to a concrete playback failure mode. Read deeper: Cross-Region Object Missing.

The durable-outbox/job-record handoff guarantees the job's existence regardless of the publish outcome; a dispatcher retries until the queue acknowledges it. Read deeper: Finalize DB Commit, Job Publish Fails.

Attempt-specific staging paths plus a safe publication boundary — duplicate execution is a cost, never a correctness risk. Read deeper: Duplicate Processing Job.

It indicates a bypass of the publication boundary — manifests must only be published after their full segment set is written and validated, as one atomic step. Read deeper: Manifest Published Before Segments.

Roll back the active-version pointer to the last known-good version (retained, not deleted, until superseded safely), and quarantine the bad version for investigation rather than deleting the evidence. Read deeper: Bad Transcode Published.

Confirm origin shield/tiered caching is absorbing cross-edge fan-in and request coalescing is active; avoid a global cache purge as the fix (stagger it instead); apply origin-side rate limiting if the shield itself is under real pressure. Read deeper: CDN Cache-Miss Storm.

No — unrestricted origin fallback at scale is exactly the mistake to avoid; use bounded fallback, alternate edge/shield routing, safe stale-serving where acceptable, and load shedding instead. Read deeper: Origin Protection.

Only what was actually designed to survive it — cached reads can cover some playback/browsing if that path was built to tolerate primary unavailability, but this isn't automatic; new uploads/finalizes and fresh writes are blocked until a replica is promoted, which itself has replication-lag/RPO implications. Read deeper: Metadata Database Failure.

Privacy-restricting changes need explicit, high-urgency invalidation of cached authorization results and CDN-cached content — waiting for an ordinary metadata TTL to expire is not acceptable for this class of change. Read deeper: Metadata Cache Stale Privacy.

Stopping new authorization and discovery should happen immediately; CDN purge/derived-artifact deletion is a distributed workflow that may take longer, and that gap should be explicit and monitored rather than silently assumed away — never promise instantaneous global physical deletion unless it's actually guaranteed. Read deeper: Video Deleted, CDN Still Cached.

No — playback must remain unaffected; telemetry is not on the playback critical path, and how it degrades (buffer-and-retry vs. bounded drop) should be an explicit design decision, not an emergency one. Read deeper: Telemetry Pipeline Outage.

Already-cached CDN content for objects replicated elsewhere is largely unaffected; new uploads/processing local to that region fail until routed elsewhere, and only if ownership/fencing/replication were actually designed to support that redirection; in-progress multipart uploads tied to that region generally do not seamlessly continue. Read deeper: Regional Failure.

Treat it as a hot-key problem specific to that aggregation partition — shard or hierarchically aggregate that key rather than assuming the general batching design automatically scales to arbitrary concentration on one key. Read deeper: Hot View Aggregation Key.