Functional
- Put, get, head, list, and delete versioned objects.
- Support multipart upload and byte-range reads.
- Apply retention, lifecycle, and access policies.
End-to-end walkthrough
Object Storage
Store enormous immutable blobs durably with metadata, multipart upload, and repair.
Frame before solving
Requirements & boundaries
Quality attributes
- Extremely high durability across independent fault domains.
- Strong read-after-create for object metadata.
- Streaming throughput scales independently of metadata QPS.
Explicitly out of scope
- POSIX file semantics and in-place writes.
- Content indexing or media transformation.
Size the important constraints
Back-of-the-envelope estimates
Metadata compactness and repair bandwidth dominate.
Namespace metadata must be partitioned and continuously rebalanced.
Inline tiny objects; multipart and chunk large ones.
Detection and repair are steady-state workloads.
These are reference assumptions, not universal facts. In an interview or architecture review, change them when the product context changes.
Define the contract
API & data model
Core operations
/{bucket}/{key}Create a new immutable version conditionally./{bucket}/{key}?uploadsBegin multipart upload and return upload_id./{bucket}/{key}Stream current/versioned object with range support.Authoritative records
bucket+key+version, manifest, etag, size, policy, created_atManifest references immutable fragments.fragment_id, placement_set, checksum, lengthPlacement spans racks/zones and records coding scheme.Trace the critical path
Architecture & request flow
- 1Authorize request→
- 2Write object fragments→
- 3Reach durability threshold→
- 4Commit metadata→
- 5Serve through edge caches
Metadata service
Map object names to versions and fragments
Storage nodes
Persist erasure-coded or replicated chunks
Repair service
Detect and rebuild lost fragments
Edge layer
Cache and accelerate downloads
Reason about the hard parts
Critical design deep dives
Commit protocol
Upload fragments first, verify checksums and durability threshold, then conditionally commit the metadata manifest. Uncommitted fragments are invisible and later garbage-collected.
Replication versus erasure coding
Replicate new/hot/small objects for fast writes and repair; convert cold large objects to erasure coding. Coding reduces overhead but increases read amplification and repair CPU/network.
Repair and scrubbing
Continuously checksum data, prioritize repairs by remaining fault-domain diversity, throttle against foreground traffic, and track durability debt. Placement must avoid correlated hardware and software risk.
Make trade-offs explicit
Architecture decisions
ChoiceWhyCost
Erasure codingReduces storage overheadRepair and small reads use more compute/network
Immutable versionsSimplifies replication and recoveryDeletion requires lifecycle management
Failure-first review
What happens if…?
Disk or rack is lost
Reconstruct fragments across fault domains before durability debt compounds.
Metadata commit is uncertain
Use an idempotent upload session and garbage-collect unreferenced fragments.
Avoid premature complexity
How the design evolves
Regional store
Replicated chunks + strongly consistent metadata
Move here when: Simple durable blob service.
Cost scale
Erasure coding, lifecycle tiers, multipart upload
Move here when: Storage cost and large objects dominate.
Global service
Cross-region policies, edge caching, autonomous repair
Move here when: Residency, disaster tolerance, and download latency.
Test the reasoning
Interview follow-ups
When is a successful PUT visible?
Strong answer signal: After an authoritative manifest commit, not after every background copy.
How do you delete safely with concurrent reads?
Strong answer signal: Tombstone/version metadata first; reclaim immutable fragments later.
Why is listing harder than getting?
Strong answer signal: Ordered namespace scans cross partitions and need snapshot/page-token semantics.
Build from primitives