Design deduplicated file storage on filesystem

Quick Overview

This question evaluates system design and storage engineering competencies, including multi-tenant isolation, authentication and authorization models, content-addressable storage and deduplication, reference counting and garbage collection, concurrency control, API surface design, and scaling across nodes using only filesystem primitives.

Design deduplicated file storage on filesystem

Company: Google

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Technical Screen

Design a multi-tenant file storage service where users can upload, get, and delete files. Identical files should be deduplicated; users must be isolated from each other. You may not use a database—only OS filesystem APIs. Define authentication and authorization (who can upload), object naming, APIs, content-addressed storage, reference counting and garbage collection, consistency under concurrent updates and deletes, and scaling across multiple storage nodes.

Quick Answer: This question evaluates system design and storage engineering competencies, including multi-tenant isolation, authentication and authorization models, content-addressable storage and deduplication, reference counting and garbage collection, concurrency control, API surface design, and scaling across nodes using only filesystem primitives.

|Home/System Design/Google
Google logo
Google
Sep 6, 2025, 12:00 AM
hardSoftware EngineerTechnical ScreenSystem Design
12
0

System Design Task: Filesystem-Only, Multi-tenant, Deduplicated File Storage

You are asked to design a multi-tenant file storage service with the following constraints and requirements:

  • Only OS filesystem APIs are allowed (e.g., directories/files, permissions, hard links/symlinks, atomic rename, file locks, fsync). No databases or external KV stores.
  • Users belong to tenants; tenants must be isolated from each other.
  • Identical files must be deduplicated.
  • Define and justify the following:
    1. Authentication and authorization (who can upload, read, delete).
    2. Object naming and tenant namespace layout.
    3. External APIs (upload, get, delete; optionally list, head, copy).
    4. Content-addressed storage and deduplication strategy.
    5. Reference counting and garbage collection.
    6. Consistency and concurrency semantics under concurrent uploads/updates/deletes.
    7. Scaling across multiple storage nodes (sharding, replication assumptions, routing).

Assume a POSIX-like environment supporting atomic rename, hard links, advisory file locks, and SHA-256 hashing.

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...