Blob / Object Storage

What it is

Object storage (S3, GCS, Azure Blob, MinIO) stores immutable-ish blobs addressed by bucket + key over HTTP(S). Optimized for large sequential reads/writes, durability (replication, erasure coding), and cheap $/GB—not POSIX filesystem semantics.

Core concepts

• Bucket: namespace and policy boundary.
• Object key: logical path string (implementation may shard by prefix).
• Presigned URL: short-lived delegated permission for a client to upload or download a specific object without sending bytes through app servers.
• Multipart upload: split large objects into parts uploaded in parallel; commit assembles with ETags; resume failed parts. Essential for large uploads and unreliable networks.
• Lifecycle rules: transition to infrequent / archive tiers; expire old versions or incomplete multipart uploads after abandonment.
• Versioning / overwrite semantics: object stores are not POSIX filesystems. Overwriting a key usually creates a new object version if versioning is enabled, or replaces the object atomically for future reads if not.
• Metadata catalog: many systems keep object ownership, status, checksums, and search fields in a database; object storage keeps the bytes.

  Client -- initiate multipart --> get uploadId
  Client -- upload part N --> store part
  Client -- complete --> assembled object visible

Concrete example

For a video upload, the app API authenticates the user, creates a metadata row with status uploading, starts a multipart upload, and returns presigned part URLs with size, content-type, and expiry constraints. The client uploads parts directly to object storage, calls complete, then the backend verifies checksum/ETag, marks the object active, and queues thumbnailing or transcoding. A lifecycle rule aborts incomplete multipart uploads if the client disappears.

Consistency and metadata

Most interview designs should treat object storage and metadata storage as two systems. The database says who owns the object, what state it is in, and how it should appear in product flows; object storage holds the bytes.

• Upload state: use states such as uploading -> active -> deleting so readers do not see half-finished objects.
• Read-after-write: new keys are typically visible quickly, but design product correctness around metadata state rather than bucket scans.
• Overwrite behavior: prefer immutable keys plus a metadata pointer update for user-visible replacement; versioned buckets help recovery and audit.
• Mismatch handling: reconcile metadata rows without committed objects and objects without active metadata.

Upload completion workflow

1. Create a metadata row in uploading state with owner id, expected size, content type, checksum policy, and object key prefix.
2. Issue short-lived presigned part URLs for that exact key or upload id; include size and content-type constraints when the provider supports them.
3. Client uploads parts directly to object storage and calls a backend completion endpoint.
4. Backend verifies the committed object, checksum or ETag expectations, owner, and metadata state before marking the row active.
5. Background reconciliation cleans up expired uploading rows, aborts incomplete multipart uploads, and quarantines objects that have no active metadata.

Presigned URL safety

• Keep expiries short and scope each URL to one object key, one operation, and the least privilege needed.
• Bind upload policy to expected content length, content type, tenant prefix, and server-generated object key rather than trusting a client-chosen path.
• Do not expose private bucket keys directly as stable product identifiers; store an internal object key behind product metadata.
• Log issuance and completion separately so abuse investigations can connect a user, key, IP, and object version.

When to use

• User-generated content: images, video, PDFs, backups.
• Data lake files (Parquet, CSV) for analytics.
• Static assets behind reverse-proxy-cdn.

Alternatives

• Block storage (EBS): attached volumes for databases—not shared blob semantics.
• NFS shared file: POSIX; harder at cloud scale for internet-facing blob workloads.

Storage comparison

Sizing example

If users upload 500K videos/day at 20 MB each, new storage grows by about 10 TB/day before replication, versions, and thumbnails. If users download 2M videos/day at 20 MB, user-facing egress is about 40 TB/day. With a 90% CDN hit ratio, origin reads fall to roughly 4 TB/day, but CDN-to-user egress still needs a cost budget.

Failure modes

• Public bucket misconfiguration: data leak; use bucket policies, block public access defaults.
• Incomplete multipart junk consuming space—lifecycle abort cleanup.
• LIST heavy workloads with huge prefixes—expensive; use inventory or metadata DB for catalog.
• Hot prefix throttling on some providers—distribute key prefixes (shuffle).
• Broken access boundaries: presigned URLs that live too long, allow the wrong key prefix, or skip content-length/content-type checks.
• Missing integrity checks: client says upload succeeded, but metadata, checksum, or part list does not match the committed object.

Common mistakes

• Sending large files through API servers instead of direct upload to object storage.
• Using object storage as a low-latency random-write filesystem.
• Depending on bucket LIST as the source of truth for user-facing search or folder views.
• Forgetting encryption, retention, deletion, and audit requirements for regulated data.

Operational signals

• Storage bytes by tier, request rate, 4xx/5xx rate, first-byte latency, multipart abort count, lifecycle transition count, and CDN hit ratio.
• Egress cost, cross-region replication lag, object-not-found rate after metadata commits, and checksum mismatch rate.

Interview talking points

• Presigned URLs: client uploads/downloads direct to object storage, bypassing app servers (ties to api-gateway for auth issuance only).
• Durability vs latency: first-byte latency higher than SSD; design for large sequential patterns.
• Estimate cost and egress with back-of-envelope; note egress dominates bill for global users—pair with CDN.

Interview answer shape

1. Start with workload: object size distribution, upload/download QPS, durability, privacy, retention, and global access.
2. Store bytes in object storage and store metadata, ownership, search fields, and processing status in a database.
3. Use presigned URLs and multipart upload for large client uploads; avoid app-server byte proxying.
4. Put CDN in front of hot public or authorized downloads when cacheability and access rules allow it.
5. Cover operations: lifecycle tiers, incomplete upload cleanup, versioning, encryption, audit logs, egress cost, and replication needs.

Common follow-ups: object storage vs block storage vs NFS, presigned URL security, multipart retries, metadata DB consistency, CDN invalidation, versioning, regional replication, and cost estimation.

Follow-up answers

• Object vs block vs file storage: object storage is for durable bytes behind bucket/key APIs; block storage is for low-level volumes attached to compute; file storage is for POSIX-style shared directories and locks.
• Metadata consistency: make metadata the product source of truth, use states such as uploading and active, verify object existence before publishing, and run reconciliation for orphan rows or orphan objects.
• Multipart retries: retry failed parts independently, keep the upload id until completion or abort, and apply lifecycle cleanup so abandoned uploads do not leak storage.
• CDN invalidation: prefer immutable versioned object keys for public assets. Use purge APIs only when keys cannot change, and estimate origin load after purges.
• Regional replication: use it for durability, disaster recovery, or global reads, but discuss replication lag, data residency, and cross-region cost.

Interview questions

1. How would you design direct video upload without sending the file through app servers?
2. How do you keep object bytes and metadata consistent when upload completion or processing fails?
3. When should you put a CDN in front of object storage, and what costs or security constraints change?

Memory hooks

• Object storage holds bytes; a database owns product metadata and state.
• Use presigned multipart upload for large client files.
• Cost is often dominated by egress and hot-object delivery, not only stored GB.

Related fundamentals

• Back-of-envelope estimation
• Latency and throughput