File Storage & Sync: Interview Perspective

Clarify scope explicitly — sync, conflict resolution, and offline handling are a substantially different (and larger) problem than upload/download/storage alone. State which you're covering and why, rather than assuming.

• What's the maximum file size we need to support? — Drives chunking strategy and part-count/size trade-offs — see Trade-offs & Decisions → Chunk/Part Size Selection.
• Do we need offline editing? — If yes, the sync client state machine and conflict handling become first-class, not optional — see Architecture Deep Dive → Sync Client State Machine.

Push back on scope creep toward active-active global metadata unless the interviewer specifically asks for it — a bounded single-region-primary-with-DR-failover story is defensible for a foundations design.

• What availability vs durability trade-off matters more here? — These are different properties — durability is about not losing data, availability is about being reachable; see Architecture Deep Dive → Disaster Recovery and Multi-Region.

At scale, proxying bytes through the application tier consumes bandwidth, holds long-lived connections, and couples data-transfer availability to control-plane availability. Direct upload via a presigned URL keeps the application tier lightweight — orchestration and authorization only.

• How do presigned URLs actually work? — See Architecture Deep Dive → Presigned URL Security — emphasize bearer-capability semantics, not 'non-transferable.'
• What if the URL expires mid-upload? — See Failure & Scale → Presigned URL Expiry — differentiate URL expiry, session expiry, and credential/policy changes.

Chunked/multipart upload with a durable session: the client (or service, where supported) reconciles which parts are actually confirmed in storage, then uploads only the missing parts before an idempotent completion call.

• How do you choose part size? — Provider limits, part-count ceiling, file size, network conditions, client memory, and parallelism — not a fixed 5–10MB rule; see Trade-offs & Decisions → Chunk/Part Size Selection.
• What if the object upload succeeds but the metadata commit fails? — Central consistency failure — see Architecture Deep Dive → Metadata/Object Consistency and Failure & Scale Scenarios → Upload Completes in Storage but Metadata Commit Fails.

Distinguish transport (TLS), per-part checksum, whole-object checksum, and application content hash. The completion step should verify the assembled object against an expected checksum before marking it AVAILABLE.

• Is ETag always a reliable integrity checksum? — No — ETag semantics vary by provider, encryption mode, and multipart behavior; don't assume ETag == MD5. See Architecture Deep Dive → End-to-End Data Integrity.

They're different workloads: metadata needs queryable, relational, frequently-updated small records; bytes need durable, cheap, large-object storage with independent scaling. For this design's scale, this separation is the foundational decision — but note it's a workload-driven choice, not a claim that databases can never store any blobs.

• How do you keep the two systems consistent? — There's no ordinary atomic transaction spanning both — see Architecture Deep Dive → Metadata/Object Consistency for the verify-then-publish state machine.

Rename and move are extremely common operations; if identity were the path, every rename would be an identity change. A stable file_id lets rename/move be cheap metadata mutations, and lets sync clients recognize 'same file, new name' instead of treating it as delete-plus-create.

• How does that affect folder listing and uniqueness? — See Architecture Deep Dive → Metadata Model, Namespace & Folder Hierarchy — listing by parent_folder_id, optional (parent_folder_id, normalized_name) uniqueness.

A filesystem watcher (inotify/FSEvents/ReadDirectoryChanges-style) plus a periodic full reconciliation scan as a safety net against missed events.

It calls a durable, cursor-based change endpoint. Push notifications are only a wake-up hint that something changed — the durable change log, not the push payload, is the source of truth.

• Why use a cursor instead of a timestamp? — Avoids clock-skew bugs between devices and the server; a cursor represents 'all changes up to X have been processed.'
• What if the device missed the push notification entirely? — See Failure & Scale → Sync Notification Service Down — reconnect/periodic polling catches up regardless.

If it's offline longer than the server retains change history, incremental cursor replay is no longer possible. The fallback is a full metadata snapshot, comparison against local state, reconciliation of any pending local operations, and establishing a fresh cursor.

• How do you handle duplicate or out-of-order sync events? — Operation IDs and version checks make replay idempotent and order-safe — see Architecture Deep Dive → Ordering and Idempotency.

No. It only tells you that content changed. Identifying which bytes changed requires block-level signatures or a content-defined-chunking/rolling-checksum approach.

• When is delta sync not worth it? — Compressed, encrypted, or otherwise binary-dense formats can have a small logical edit that changes much of the byte representation — whole-file replacement may be simpler and equally effective.

Whole-file is simplest and best for small/incompressible-delta files. Fixed blocks are simple but broken by insertions shifting subsequent boundaries. Rolling checksums (rsync-style) find matching regions despite shifted offsets, at the cost of CPU and chunk-index metadata.

Both submit a mutation based on the same parent version. The server detects the version fork (not by timestamp) and, by default, preserves both as conflict copies rather than silently picking a winner.

• Why not just use timestamps / last-write-wins? — Clock skew between devices makes timestamp-based ordering unreliable, and last-write-wins silently discards one side's work — that's a product policy choice, not a distributed-systems requirement.
• When is three-way merge possible? — For mergeable text formats using the common ancestor version — not for binary files, and not a substitute for real-time collaborative editing (CRDT/OT), which is out of scope here.

This is a delete/edit race. Tombstone (soft-delete) semantics let the reconnecting device learn the file was deleted rather than silently re-uploading its edit as a brand-new file. Product policy then decides: restore as conflict copy, reject as stale, or create a recovered file.

An ACL check on every file operation, backed by a permissions table recording owner, direct shares, and folder-inherited permissions with defined override rules.

The already-issued URL remains usable until it expires — revocation is not retroactive for a plain bearer-capability URL. Mitigate with short TTLs, and use a stricter token-validation/proxy path only if instant revocation is a hard requirement.

• Can a signed URL be shared/forwarded by the recipient? — Generally yes — treat it as a bearer capability unless the design adds an explicit additional binding mechanism. Don't claim it's non-transferable.

Fail closed. Serving a stale cached 'allowed' answer during a metadata outage risks honoring a permission that has since been revoked.

Either can work; avoid caricatures like 'NoSQL means no joins' or 'SQL means vertical-only.' Compare on transaction model, access patterns, secondary-index support, consistency needs for ACL enforcement, and sharing-query shape. A relational store is a reasonable illustrative choice given this design's join-heavy sharing queries.

Owner/user sharding gives good 'my files' locality but a large tenant can become a hot shard, and cross-owner sharing queries need a secondary recipient-oriented index rather than scanning every shard.

• How do you handle a hugely oversized tenant or a huge shared folder? — Paginated listings, asynchronous fan-out, and per-tenant fairness limits — see Failure & Scale Scenarios → Hot User / Huge Shared Folder.

One immutable object per committed version; current metadata points to the current version. Retention (keep-all, time/count/quota-based) is a separate policy layered on top — don't conflate the application's version concept with a storage provider's native object versioning feature.

Never delete a blob solely because one transient metadata lookup says it's unreferenced. Use soft-delete with a grace period, idempotent GC jobs, and periodic audit/reconciliation — GC bugs here are one of the few failure modes that can cause genuine permanent data loss.

It's workload-dependent — public/shared immutable content benefits most from caching; private/high-cardinality files may see little reuse. If private content is CDN-delivered at all, it needs its own signed-URL/cookie authorization design at the edge — an ordinary object-storage presigned URL doesn't automatically become CDN-backed.

• How do immutable/versioned object keys help? — A new version gets a new key/URL, sidestepping most cache-invalidation problems instead of relying solely on purging a mutable URL.

HTTP range requests — resume from the last received byte, fetch partial ranges, or support streaming/preview without downloading the whole object first.

Bounded retry with backoff/jitter; metadata browsing can remain available; in-progress multipart uploads need explicit reconciliation on recovery, not an assumption of automatic resume.

Fail closed for authorization-sensitive operations; don't rely on an in-memory application write queue as a durable recovery mechanism; failover time is deployment-specific, not a fixed number.

This is the central metadata/object consistency failure. Idempotent completion plus a reconciliation job that verifies storage state and safely commits AVAILABLE (or garbage-collects a truly orphaned object after a grace period) is the answer.

Push is an optimization, not the source of truth — clients fall back to cursor-based polling on reconnect and still catch up, just with higher latency.