Bird
Raised Fist0

Block Storage vs Object Storage vs File Storage - When to Use Which

HLDmediumInterview freq: medium
Choose your preparation mode4 modes available
▶
Request Trace
Step 1/5
Metadata Service

Receives client request to store data

Determines storage type based on data size and access pattern

Protocol:REST API
BeforeClient request just arrived with data and metadata
AfterMetadata Service identified storage type and routes request
Block Storage

Allocates raw volume for data

Prepares block device for low-latency random access

Protocol:iSCSI / Fibre Channel
BeforeMetadata Service routed request to Block Storage
AfterBlock Storage allocated volume and ready for data write
SAN/NVMe Storage Backend

Stores raw blocks persistently

Handles low-level I/O with high throughput and low latency

Protocol:NVMe over Fabrics
BeforeBlock Storage has volume allocated but no data stored
AfterData blocks durably stored on SAN/NVMe backend
Object Storage

Stores immutable object with metadata

Accepts HTTP PUT with object data and metadata

Protocol:HTTP(S)
BeforeMetadata Service routed request to Object Storage
AfterObject stored with unique ID and metadata
File Storage

Provides shared filesystem access

Exports POSIX filesystem for multiple clients

Protocol:NFS / SMB
BeforeClient requests shared file access
AfterFile Storage exports filesystem mounted by clients
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│ Metadata      │
│ Service       │
└───────┬───────┘
        │ REST API
        ▼
┌───────────────┐
│ Block Storage │
│ (raw volumes) │
└───────┬───────┘
        │ iSCSI / Fibre Chan.
        ▼
┌───────────────────────┐
│ SAN/NVMe Storage      │
│ Backend (low latency) │
└───────────────────────┘
        ▲
        │
┌───────┴───────┐
│ Object Storage│
│ (immutable objs)│
└───────┬───────┘
        │ HTTP(S)
        ▼
┌───────────────┐
│ File Storage  │
│ (shared FS)   │
└───────────────┘

This architecture illustrates three storage types and their typical use cases. The Metadata Service acts as the entry point, deciding which storage system fits the client's data based on size and access patterns. Block Storage provides raw volumes backed by a SAN/NVMe backend, ideal for low-latency, high-throughput workloads requiring OS-level control. Object Storage stores immutable objects with metadata accessible via HTTP, suited for large unstructured data and cloud-native apps. File Storage offers shared POSIX-compliant file systems for collaborative workloads. Each storage type interfaces with the backend differently, reflecting their design trade-offs and usage scenarios.

Primary Focus

✓

Practice

(1/5)
1. A web application experiences increasing CPU load on a single database server, causing query latency spikes. Which scaling approach best addresses this bottleneck without changing the application code?
easy
A. Distribute the database load by sharding data across multiple servers (horizontal scaling)
B. Add more CPU cores and RAM to the existing database server (vertical scaling)
C. Use a caching layer in front of the database to reduce read load
D. Switch from SQL to NoSQL database to improve write throughput

Solution

  1. Step 1: Identify the bottleneck as CPU and memory on a single DB server

    Vertical scaling adds resources to the existing server to handle more load without architectural changes.
  2. Step 2: Evaluate horizontal scaling and other options

    Horizontal scaling requires application changes for sharding; caching reduces reads but not CPU-bound writes; switching DB types is a different trade-off.
  3. Final Answer:

    Option B -> Option B
  4. Quick Check:

    Vertical scaling adds resources to one server without code changes [check]
Hint: Vertical scaling adds power to one machine [check]
Common Mistakes:
2. For a distributed cache requiring high availability and low latency, which replication strategy is best when network partitions are frequent?
medium
A. Asynchronous replication with eventual consistency
B. No replication, rely on client retries
C. Synchronous replication with strong consistency
D. Quorum-based replication with majority writes

Solution

  1. Step 1: Analyze replication under network partitions

    Synchronous replication blocks writes on slow or unreachable replicas, hurting availability.
  2. Step 2: Asynchronous replication tolerates partitions

    Allows writes to proceed locally and replicates changes later, favoring availability over immediate consistency.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Async replication favors availability during partitions [check]
Hint: Async replication favors availability under partitions [OK]
Common Mistakes:
3. For a global e-commerce platform requiring high availability and multi-region writes with eventual consistency, which key-value store choice is best and why?
medium
A. Use DynamoDB Global Tables for multi-region writes and automatic conflict resolution
B. Use Redis with master-slave replication across regions for low latency
C. Use Redis Cluster with cross-region sharding and manual conflict handling
D. Use a relational database with cross-region synchronous replication

Solution

  1. Step 1: Identify multi-region write and availability requirements

    Multi-region writes require conflict resolution and high availability without synchronous blocking.
  2. Step 2: Compare Redis and DynamoDB capabilities

    DynamoDB Global Tables support multi-region writes with built-in conflict resolution and eventual consistency; Redis lacks native multi-region write support.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    DynamoDB Global Tables -> multi-region writes with conflict resolution [check]
Hint: DynamoDB Global Tables handle multi-region writes natively [check]
Common Mistakes:
4. At 10x scale, which component in a consistent hashing database sharding system is most likely to fail first and why?
hard
A. The central shard metadata service, due to increased coordination overhead
B. The individual database shards, because storage capacity limits are reached first
C. The hash ring management service, because updating and propagating ring changes becomes a bottleneck
D. The client-side routing cache, as it cannot handle the increased number of shards efficiently

Solution

  1. Step 1: Identify scaling bottlenecks

    Central metadata service (The central shard metadata service, due to increased coordination overhead) may be distributed or avoided; shards (The individual database shards, because storage capacity limits are reached first) scale horizontally; client caches (The client-side routing cache, as it cannot handle the increased number of shards efficiently) can be sharded or refreshed incrementally.
  2. Step 2: Analyze hash ring management at scale

    Hash ring management (The hash ring management service, because updating and propagating ring changes becomes a bottleneck) requires updating and propagating ring changes to all nodes; at 10x scale, this coordination overhead and update frequency cause it to become the first bottleneck.
  3. Final Answer:

    Option C -> Option C
  4. Quick Check:

    Hash ring updates bottleneck first at large scale [check]
Hint: Hash ring updates bottleneck first at large scale [OK]
Common Mistakes:
5. At 10x scale, which component is most likely to become the bottleneck first in the real-time driver location tracking system, and why?
hard
A. The database storing driver locations, due to write amplification from frequent updates
B. The WebSocket servers maintaining live connections, due to stateful connection limits and memory pressure
C. The surge pricing service, due to complex pricing calculations under load
D. The mobile clients, due to network bandwidth constraints

Solution

  1. Step 1: Identify stateful components in location tracking

    WebSocket servers hold persistent connections per driver and rider, consuming memory and CPU.
  2. Step 2: Analyze scaling challenges

    At 10x scale, WebSocket servers hit connection limits and memory pressure first; databases can shard and cache; surge pricing is stateless and scalable; mobile clients scale independently.
  3. Final Answer:

    Option B -> Option B
  4. Quick Check:

    Stateful WebSocket servers bottleneck first due to connection limits [check]
Hint: Stateful WebSocket servers hit limits before stateless components [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard