Katkat
Back

Design an S3-like Object Store

DropboxSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This problem evaluates your ability to design a distributed, highly available, and scalable object storage system capable of handling massive volumes of unstructured data.

Problem Statement

Design a distributed object store similar to Amazon S3. The system should allow users to upload, download, and delete unstructured files (objects) of varying sizes (from bytes to terabytes).

Functional Requirements

  • put(bucket, key, data): Store an object.
  • get(bucket, key): Retrieve an object.
  • delete(bucket, key): Remove an object.
  • list(bucket): List objects in a bucket.

Non-Functional Requirements

  • Durability: Data must be highly resistant to hardware failure.
  • Availability: The system should remain operational during individual node failures.
  • Scalability: The system must support petabytes of data and high request throughput.
  • Consistency: Assume eventual consistency is acceptable, but discuss the trade-offs.

Deliverables

  1. High-level architecture (API Gateway, Metadata Service, Data Storage Service).
  2. Strategy for partitioning and mapping keys to physical storage nodes.
  3. Approach for handling large objects (multi-part uploads).
  4. Data placement strategy (Replication vs. Erasure Coding).

Assumptions

  • You have access to a distributed key-value store (e.g., etcd or Zookeeper) for metadata.
  • You have block-level storage devices on individual nodes.

Hints

Hint 1

Consider decoupling the metadata (file pointers, permissions) from the actual object binary data stored on disk.

Hint 2

Think about how to handle objects larger than the capacity of a single storage node using chunking or multi-part upload protocols.

Hint 3

Compare the space-efficiency of replication versus erasure coding for data durability at scale.

Follow-up questions

  • How would you implement object versioning so that a user can retrieve older versions of a file if they overwrite it?
  • How would you handle background garbage collection for objects that were partially uploaded or deleted but not yet purged from physical storage?
  • If the system requires strict read-after-write consistency, how would the architecture change?