# Object storage > Object storage, also called blob storage, stores files as objects addressed by keys rather than disk blocks or filesystem paths. In system design, it holds large content such as photos, videos, and backups while a database manages ownership, permissions, and searchable metadata. Source: https://sysround.com/concepts/object-storage Updated: 2026-11-05 ## How object storage works An object contains bytes and metadata and lives under a key in a bucket or container. For example, the key photos/user-42/image-781/original.jpg identifies an image. Slashes usually organize key names; they do not imply real directories with filesystem rename semantics. Applications use APIs such as PUT, GET, HEAD, and DELETE. Objects are generally replaced as a whole rather than modified in place, though range reads let clients fetch part of an object. Multipart uploads split a large transfer into independently retryable parts and assemble the object when the upload completes. Separate the content path from the metadata path. Store image bytes in object storage and a database row containing the owner, object key, size, checksum, and publication state. Query the database to find a user's photos; do not scan bucket listings to implement an application feed or search index. For direct uploads, the application authenticates the user, allocates an upload session and key, and issues a short-lived signed upload URL. The client sends bytes directly to object storage instead of routing them through application servers. Before publishing, the backend verifies the stored object and enforces size, type, and processing requirements. Treat upload completion and application publication as separate steps because the object store and metadata database usually do not share a transaction. Keep metadata pending until required objects and derivatives exist, then mark it ready. Make completion retries idempotent and reconcile abandoned uploads, missing objects, and unreferenced objects. Serve public media through a CDN using versioned object keys; authorize private downloads before issuing short-lived access. Underneath, object storage distributes data across devices and failure domains using replication or erasure coding. Consistency guarantees depend on the store and operation: object storage is not inherently eventually consistent, and a strongly consistent origin does not make CDN caches or cross-region replicas instantly fresh. ## Worked example: Publishing a photo only after its files are ready Suppose a photo service receives 100,000 uploads per day, averaging 8 MB each: about 800 GB of new originals daily, before derivatives and storage redundancy. The API creates a pending photo row and issues signed upload access for a unique versioned key. The client uploads directly, retrying failed parts. A completion handler verifies size and checksum, then schedules thumbnail generation. Workers write two thumbnails under versioned keys and retry safely if interrupted. Only after the required outputs exist does the database mark the photo ready. Reads return CDN URLs for ready photos. A reconciler recovers stalled work, while lifecycle rules expire abandoned multipart uploads. Originals follow a separate retention policy. ## Trade-offs - **Large-object storage versus database convenience.** Moving bytes out of the database reduces its storage and backup burden, but introduces a separate system whose lifecycle must stay aligned with metadata. - **Scalable transfers versus fine-grained mutation.** Object APIs suit parallel uploads and downloads but are usually a poor fit for frequent small in-place updates or filesystem-style operations. - **Direct uploads versus application control.** Direct uploads spare application-server bandwidth, but require narrowly scoped credentials, upload validation, quotas, and cleanup of abandoned transfers. - **Durability versus overhead.** Replication and erasure coding protect against storage failures at different capacity and repair costs, but neither replaces recovery planning for accidental deletion. - **Cheap capacity versus total delivery cost.** Budget for requests, retrieval, replication, and network egress as well as stored bytes, especially when popular media is downloaded repeatedly. - **Caching versus timely revocation.** CDNs improve delivery latency and reduce origin traffic, but previously issued URLs and cached responses can outlive a permission change unless access and expiry rules address that. ## When to use it in a system design interview - The design stores large photos, videos, attachments, documents, or backups alongside relatively small metadata records. - Clients need resumable or parallel transfers without making application servers relay every byte. - The workload writes content once and reads it many times, often through a CDN. - You need a durable home for originals and generated derivatives, with separate retention or archival policies. - A file-storage interface needs to scale independently from directory listings, search, sharing, and other metadata operations. ## How to bring it up in the interview - Start with the split: object storage holds bytes; the database holds identity, ownership, permissions, versions, and publication state. Explain why database queries, not bucket listings, drive the product interface. - Walk through the complete upload lifecycle, including authorization, multipart retries, integrity checks, processing, and the transition to ready. Interviewers often ask what happens if the upload succeeds but the database update fails. - State the consistency guarantees you actually need for reads, overwrites, listings, and replication rather than labeling all object storage eventually consistent. Use versioned keys to avoid overwriting content behind long-lived caches. - Estimate stored bytes, upload bandwidth, download bandwidth, and derivative volume separately. Expect follow-ups about CDN hit rate, egress costs, object count, and retention. - Define deletion and access revocation explicitly: who can read the origin, how signed access expires, and how workers avoid recreating deleted content. Explain that deleting a metadata row alone does not remove every accessible copy. ## Common mistakes - Putting large media payloads in the primary database by default without discussing database growth, backups, and delivery bandwidth. - Assuming an uploaded object and its metadata row can be committed atomically, then exposing content before all required files are ready. - Treating object storage as a POSIX filesystem with cheap directory renames, append operations, or arbitrary in-place writes. - Claiming all object stores provide only eventual consistency, or assuming strong origin consistency also covers caches and cross-region replication. - Making a bucket public for private content or treating a signed URL as immediately revocable simply because application permissions changed. ## Interview questions where it comes up - [Design a video streaming service like YouTube](https://sysround.com/questions/design-youtube): Original uploads, transcoded renditions, and streaming segments need durable object storage behind the processing pipeline and CDN. - [Design Instagram](https://sysround.com/questions/design-instagram): Safe publication requires coordinating stored originals and derivatives with post metadata before exposing media to feeds. - [Design TikTok](https://sysround.com/questions/design-tiktok): Making an upload safely playable depends on storing and verifying processed media before publishing playback metadata. - [Design Dropbox or Google Drive](https://sysround.com/questions/design-dropbox): Resumable file transfers and versioned content must be coordinated with small metadata transactions and conflict handling. - [Design Google Photos](https://sysround.com/questions/design-google-photos): Reliable private-media backup requires retry-safe uploads, durable originals, asynchronous derivatives, and controlled downloads. - [Design Facebook Marketplace](https://sysround.com/questions/design-facebook-marketplace): Publishing listings safely requires coordinating photo uploads with database state and subsequent search indexing. ## FAQ ### What is the difference between object storage and blob storage? The terms usually describe the same broad model: storing opaque byte sequences under keys and accessing them through an API. Product details differ, so check object size limits, upload protocols, consistency guarantees, and access controls rather than relying on the name. ### How is object storage different from file storage and block storage? Object storage exposes keyed objects through an API. File storage exposes files and directories with filesystem operations, while block storage exposes addressable blocks that an operating system or database organizes. Choose based on required access patterns and semantics, not just data size. ### Should images and videos go in object storage or a database? A common design stores the bytes in object storage and keeps keys, ownership, searchable attributes, and processing state in a database. This lets media capacity and delivery scale separately from metadata queries. Small blobs or workloads needing transactional coupling may justify database storage, but explain the size, access pattern, and operational cost. ## Related concepts - [Content delivery networks (CDN)](https://sysround.com/concepts/cdn) - [Erasure coding](https://sysround.com/concepts/erasure-coding) - [Database replication](https://sysround.com/concepts/replication) - [Access control and RBAC](https://sysround.com/concepts/access-control) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.