Blob storage (S3, Azure Blob) in HLD - System Design Exercise

Design: Blob Storage Service

Design covers the core blob storage system including API, storage backend, metadata management, security, and lifecycle management. Does not cover client SDKs or CDN integration.

Functional Requirements

FR1: Store and retrieve large binary files (images, videos, documents) efficiently

FR2: Support upload, download, and delete operations for blobs

FR3: Provide secure access with authentication and authorization

FR4: Allow scalable storage to handle petabytes of data

FR5: Support metadata tagging for blobs

FR6: Enable versioning of blobs to keep track of changes

FR7: Provide high availability and durability of stored data

FR8: Allow lifecycle management to archive or delete old blobs automatically

Non-Functional Requirements

NFR1: Handle up to 1 million concurrent users

NFR2: Support low latency for read operations (p99 < 200ms)

NFR3: Ensure 99.9% availability

NFR4: Data durability of 99.999999999% (11 nines)

NFR5: Support eventual consistency for metadata updates

NFR6: Secure data in transit and at rest

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

API Gateway or Load Balancer

Authentication and Authorization Service

Blob Storage Nodes (object storage servers)

Metadata Database

Cache Layer for frequently accessed blobs

Lifecycle Management Service

Replication and Backup Systems

Design Patterns

Sharding and partitioning for storage scalability

Eventual consistency for metadata updates

Multi-region replication for durability and availability

Write-ahead logging for data durability

Token-based authentication (e.g., OAuth, signed URLs)

Reference Architecture

Client
  |
  v
API Gateway / Load Balancer
  |
  v
Auth Service <--> Metadata DB
  |
  v
Blob Storage Nodes (distributed object storage cluster)
  |
  v
Replication & Backup Systems
  |
  v
Lifecycle Management Service

Cache Layer (Redis or CDN) connected to Blob Storage Nodes for fast reads

Components

API Gateway / Load Balancer

Nginx, AWS ALB, Azure Front Door

Route client requests, handle SSL termination, and distribute load

Authentication and Authorization Service

OAuth 2.0, JWT tokens

Verify user identity and permissions for blob operations

Blob Storage Nodes

Distributed object storage (e.g., Ceph, custom storage nodes)

Store blob data reliably and serve read/write requests

Metadata Database

Relational DB (PostgreSQL) or NoSQL (DynamoDB)

Store blob metadata, tags, version info, and access control lists

Cache Layer

Redis or CDN

Cache frequently accessed blobs to reduce latency

Lifecycle Management Service

Scheduled jobs or serverless functions

Automatically archive or delete blobs based on policies

Replication and Backup Systems

Cross-region replication, snapshot backups

Ensure data durability and availability in case of failures

Request Flow

1. Client sends request to API Gateway to upload/download/delete blob

2. API Gateway forwards request to Authentication Service to verify user

3. If authorized, request proceeds to Blob Storage Nodes for data operations

4. Metadata updates are written to Metadata Database asynchronously

5. Blob data is stored in distributed storage with replication

6. Cache Layer serves repeated read requests to reduce latency

7. Lifecycle Management Service runs periodically to enforce retention policies

Database Schema

Entities: - Blob: id (PK), name, size, content_type, created_at, updated_at, version, storage_location - Metadata: blob_id (FK), key, value - User: id (PK), username, credentials - AccessControlList: blob_id (FK), user_id (FK), permission - LifecyclePolicy: id (PK), blob_filter, action, schedule Relationships: - One Blob has many Metadata entries - One Blob has many AccessControlList entries - Users have permissions via AccessControlList

Scaling Discussion

Bottlenecks

API Gateway overload with too many concurrent requests

Metadata Database becoming a single point of contention

Blob Storage Nodes running out of capacity or bandwidth

Cache misses causing high latency on popular blobs

Replication lag affecting data durability guarantees

Solutions

Use horizontal scaling and auto-scaling groups for API Gateway

Partition metadata database by blob ID or user to distribute load

Add more storage nodes and use sharding to balance data

Implement multi-level caching and CDN integration

Use asynchronous replication with conflict resolution and monitor lag

Interview Tips

Time: 10 minutes for requirements and clarifications, 15 minutes for architecture and components, 10 minutes for scaling and trade-offs, 10 minutes for Q&A

Clarify functional and non-functional requirements upfront

Explain choice of distributed object storage for scalability

Discuss metadata management separate from blob data

Highlight security and access control mechanisms

Address consistency and replication trade-offs

Show awareness of caching and lifecycle management

Discuss bottlenecks and scaling strategies clearly

Practice

1. What is the main purpose of blob storage services like Amazon S3 or Azure Blob Storage?

easy

A. To manage user identities and permissions

B. To run virtual machines in the cloud

C. To store large files safely and accessibly in the cloud

D. To host websites directly without any storage

Solution

1. Step 1: Understand blob storage function

   Blob storage is designed to save large files like videos, images, and backups in the cloud.

2. Step 2: Compare with other cloud services

   Other services like virtual machines or identity management serve different purposes, not file storage.

3. Final Answer:

   To store large files safely and accessibly in the cloud -> Option C

4. Quick Check:

   Blob storage = large file storage [OK]

Hint: Blob storage is for big files, not computing or identity [OK]

Common Mistakes:

• Confusing blob storage with compute services
• Thinking blob storage manages users
• Assuming blob storage hosts websites directly

2. Which of the following is the correct way to specify a bucket name in Amazon S3?

easy

A. My.bucket.name

B. MyBucketName!

C. my_bucket_name

D. my-bucket-name

Solution

1. Step 1: Review S3 bucket naming rules

   S3 bucket names must be lowercase, can include hyphens, but no underscores or special characters like '!'.

2. Step 2: Check each option

   my-bucket-name uses lowercase letters and hyphens, which is valid. Options A, B, and C are invalid: A has uppercase letters and dots, B has uppercase and '!', C has underscores.

3. Final Answer:

   my-bucket-name -> Option D

4. Quick Check:

   Bucket names use lowercase and hyphens [OK]

Hint: Bucket names: lowercase letters and hyphens only [OK]

Common Mistakes:

• Using uppercase letters in bucket names
• Including underscores or special characters
• Using dots in bucket names

3. Given this AWS CLI command:
aws s3 cp file.txt s3://my-bucket/ --storage-class STANDARD_IA
What does the --storage-class STANDARD_IA option do?

medium

A. Uploads the file to a cheaper, infrequently accessed storage tier

B. Encrypts the file automatically during upload

C. Makes the file publicly accessible

D. Uploads the file with maximum redundancy across regions

Solution

1. Step 1: Understand storage classes in S3

   STANDARD_IA means Standard-Infrequent Access, a cheaper tier for files accessed less often.

2. Step 2: Analyze command effect

   The command uploads file.txt to the bucket using this storage class, saving cost for infrequent access.

3. Final Answer:

   Uploads the file to a cheaper, infrequently accessed storage tier -> Option A

4. Quick Check:

   STANDARD_IA = cheaper, infrequent access [OK]

Hint: STANDARD_IA means cheaper storage for rare access [OK]

Common Mistakes:

• Thinking it encrypts the file
• Assuming it makes file public
• Confusing with multi-region redundancy

4. You try to upload a file to Azure Blob Storage but get an error saying the container name is invalid. Which of these is the most likely cause?

medium

A. The container name contains uppercase letters

B. The file size is too large

C. The storage account is in the wrong region

D. The file name has spaces

Solution

1. Step 1: Recall Azure container naming rules

   Container names must be lowercase letters and numbers only, no uppercase letters allowed.

2. Step 2: Match error cause

   An invalid container name error usually means the name breaks these rules, such as having uppercase letters.

3. Final Answer:

   The container name contains uppercase letters -> Option A

4. Quick Check:

   Azure container names must be lowercase [OK]

Hint: Azure containers must be lowercase, no uppercase letters [OK]

Common Mistakes:

• Blaming file size for container name errors
• Confusing region with naming rules
• Thinking file name affects container name

5. You want to store backup files in Amazon S3 with minimal cost but still need quick access sometimes. Which combination of settings is best?

hard

A. Use STANDARD storage class and enable public access for easy retrieval

B. Use STANDARD_IA storage class with lifecycle rule to move files to GLACIER after 30 days

C. Use GLACIER storage class for all files with no lifecycle rules

D. Use REDUCED_REDUNDANCY storage class and no lifecycle rules

Solution

1. Step 1: Understand storage classes and lifecycle

   STANDARD_IA offers cheaper storage with quick access. GLACIER is very cheap but slow to retrieve.

2. Step 2: Analyze cost and access needs

   Using STANDARD_IA first allows quick access. Moving to GLACIER after 30 days saves cost for older backups.

3. Step 3: Evaluate other options

   GLACIER only delays access too much. STANDARD is costly. REDUCED_REDUNDANCY is deprecated and less reliable.

4. Final Answer:

   Use STANDARD_IA storage class with lifecycle rule to move files to GLACIER after 30 days -> Option B

5. Quick Check:

   STANDARD_IA + lifecycle to GLACIER = cost + access balance [OK]

Hint: Start with STANDARD_IA, then archive to GLACIER for cost savings [OK]

Common Mistakes:

• Choosing GLACIER only and ignoring access speed
• Enabling public access unnecessarily
• Using deprecated REDUCED_REDUNDANCY class