PracHub
QuestionsLearningGuidesInterview Prep
|Home/System Design/Amazon

Design a cloud storage service

Last updated: Mar 29, 2026

Quick Overview

This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design a cloud storage service states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

  • hard
  • Amazon
  • System Design
  • Software Engineer

Design a cloud storage service

Company: Amazon

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Onsite

Design a cloud document storage and sharing service (e.g., like Google Drive). Cover requirements (upload/download, folder hierarchy, metadata/search, sharing/ACLs, versioning, trash/restore), APIs, data model, storage architecture (object store, metadata store, indexing), consistency model, partitioning and replication, upload chunking and resumability, virus scanning and thumbnails, encryption (at rest/in transit), permission checks, rate limiting, monitoring, scalability, availability, and cost considerations. Provide rough capacity estimates and a high-level diagram.

Quick Answer: This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design a cloud storage service states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Related Interview Questions

  • Design a Scalable Metrics Monitoring System - Amazon (medium)
  • Design a Personalized Weekly Deals Service - Amazon (medium)
  • Design an Amazon Locker Service - Amazon (easy)
  • Architect an AI Chatbot for Enterprise Users - Amazon (medium)
  • Design a Scalable News Feed - Amazon (easy)
|Home/System Design/Amazon

Design a cloud storage service

Amazon logo
Amazon
Aug 7, 2025, 12:00 AM
hardSoftware EngineerOnsiteSystem Design
8
0

Design a cloud storage service

System Design: Cloud Document Storage and Sharing Service

Context

Design the backend for a large-scale cloud document storage and sharing service (similar to Google Drive). Assume web and mobile clients, global user base, multi-AZ within a region to start, with a path to multi-region active-active.

Requirements

Cover the following end-to-end aspects:

  1. Functional requirements
  • Upload and download files
  • Folder hierarchy (create/move/rename)
  • Metadata and search (name, content, tags)
  • Sharing and ACLs (users, groups, link-based)
  • Versioning (restore, diff-friendly)
  • Trash and restore (soft delete, purge after retention)
  1. APIs
  • REST or gRPC endpoints for core operations
  • Chunked/resumable upload API
  • Permission management APIs
  • Search API
  1. Data model
  • Items (files/folders), versions, ACLs, shares, activities
  • Indices to support listing, search, and permission checks
  1. Storage architecture
  • Object store for blobs
  • Metadata store for items/ACLs/versions
  • Indexing/search system for content/name queries
  1. Consistency model
  • Read-after-write guarantees, eventual for search
  • Transactional semantics for rename/move/share within a user’s tree
  1. Partitioning and replication
  • Sharding strategy for metadata and search
  • Multi-AZ replication; path to multi-region
  1. Upload chunking and resumability
  • Initiation, part upload, completion, resume after failures
  1. Virus scanning and thumbnails
  • Asynchronous pipeline post-upload
  1. Security
  • Encryption in transit and at rest (key management, envelope encryption)
  • Permission checks (inherited ACLs, link tokens)
  1. Rate limiting and abuse controls
  2. Monitoring and observability
  3. Scalability, availability, and cost considerations
  4. Rough capacity estimates and a high-level diagram

Provide concrete assumptions where needed, and justify key trade-offs.

Constraints & Assumptions

  • Preserve the scope, facts, inputs, and requested outputs from the prompt above.
  • If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
  • Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask Guidance

  • Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
  • State explicit assumptions before making sizing or architecture decisions.
  • Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

  • A scoped requirements summary with concrete non-goals and success metrics.
  • API, data model, architecture, consistency, capacity, and operations.
  • Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
  • A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

  • What breaks first at 10x traffic or data volume?
  • How would you degrade gracefully during dependency failures?
  • What metrics and alerts would prove the design is healthy after launch?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...

Browse More Questions

More System Design•More Amazon•More Software Engineer•Amazon Software Engineer•Amazon System Design•Software Engineer System Design

Your design canvas — auto-saved

PracHub

Master your tech interviews with 9,000+ real questions from top companies.

Product

  • Questions
  • Learning Tracks
  • Interview Guides
  • Resources
  • Premium
  • For Universities

Browse

  • By Company
  • By Role
  • By Category
  • Topic Hubs
  • SQL Questions
  • AI Coding Questions
  • Compare Platforms
  • Discord Community

Support

  • support@prachub.com
  • (916) 541-4762

Legal

  • Privacy Policy
  • Terms of Service
  • About Us

© 2026 PracHub. All rights reserved.