Bird
Raised Fist0

Storage Tiering - Hot, Warm, Cold, Archive and Cost Optimization

HLDmediumInterview freq: medium
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Storage Tiering - Hot, Warm, Cold, Archive and Cost Optimization
Design a multi-tiered storage system balancing latency, cost, and durability for massive scale
mediumStorage SystemsFreq: medium
⚙️
Functional Requirements
  • Support multi-tier storage: hot (low latency), warm (moderate latency), cold (high latency), and archive (offline)
  • Automate data lifecycle management: move data between tiers based on age, access patterns, and cost policies
  • Provide APIs for data read/write with tier transparency to clients
  • Ensure data durability and availability per tier SLA (e.g., 99.99% for hot, 99.9% for archive)
  • Support cost optimization by minimizing expensive hot storage usage
  • Allow manual override for tier placement for special cases
📊
Non-Functional Requirements
  • Scale to 2 billion daily active users generating 40 messages per user per day
  • Support peak write throughput of ~925K writes/sec and read throughput of ~1.5M reads/sec
  • Provide 100ms P99 read latency for hot tier, 500ms for warm, 2s for cold, and batch retrieval for archive
  • Ensure 99.99% availability for hot and warm tiers, 99.9% for cold, and 99.5% for archive
  • Data retention configurable up to 7 years with tier transitions
❓
Clarifying Questions to Ask
  • What are the exact SLA requirements per tier for latency and availability?
  • What is the expected data size per message and average message size distribution?
  • How frequently does data move between tiers and what triggers tier transitions?
  • Are there any regulatory or compliance constraints affecting data retention or tiering?
  • Is the system expected to support multi-region replication or geo-distribution?
  • What is the expected read/write ratio and peak traffic patterns?
Out of Scope
✗ Designing the client-side SDK or UI for data access
✗ Data encryption and key management details
✗ Detailed backup and disaster recovery beyond tier replication
✗ Real-time analytics on stored data
📌
Assumptions
  • 2 billion daily active users (DAU)
  • 40 messages per user per day
  • Average message size: 100 bytes
  • Data retention: 7 years with tier transitions
⚡
QPS Calculation
write qps2B users × 40 msgs/user/day ÷ 86400 sec/day ≈ 925,926 writes/sec
peak write qpsAssuming 2× peak factor: 925,926 × 2 ≈ 1.85M writes/sec
read qpsAssuming 3 reads per write on average: 925,926 × 3 ≈ 2.78M reads/sec
💾
Storage Estimate
daily data2B × 40 × 100 bytes = 8 TB/day raw data
retention 7 years8 TB/day × 365 × 7 ≈ 20,440 TB ≈ 20.4 PB raw
with replication 3x20.4 PB × 3 = 61.2 PB total storage
🖥️
Server Estimate
hot storage nodesUsing Cassandra with 500 MB/s write throughput per node, need 92.6 MB/s / 0.5 MB/s ≈ 185 nodes
archive storage nodesUsing Amazon S3 Glacier with batch retrieval, no fixed node count but throughput limited by batch jobs
🏗️
Architecture Diagram
Architecture Diagram
                +----------------------+
                |      Client API      |
                +----------+-----------+
                           |
                +----------v-----------+
                |  Tiering Controller  |
                +----------+-----------+
                           |
          +----------------+----------------+----------------+
          |                |                |                |
   +------v-----+   +------v-----+   +------v-----+   +------v-----+
   |  Hot Tier  |   |  Warm Tier |   |  Cold Tier |   | Archive    |
   | Cassandra  |   |  Cassandra |   |  HDFS/     |   | Amazon S3  |
   | 3 replicas |   |  2 replicas|   |  HBase     |   | Glacier    |
   +------------+   +------------+   +------------+   +------------+
          |                |                |                |
          +----------------+----------------+----------------+
                           |
                +----------v-----------+
                |  Lifecycle Manager   |
                +----------------------+
🧩
Components
Client API
Expose read/write APIs abstracting tier details from clients
Why thisREST/gRPC APIs provide scalable, language-agnostic access with load balancing
Why notDirect DB access rejected due to tight coupling and lack of tier abstraction
Tiering Controller
Decides data placement and routes requests to appropriate storage tier
Why thisStateless microservice with consistent hashing for routing enables horizontal scaling
Why notMonolithic service rejected due to scaling bottlenecks and deployment inflexibility
Hot Tier - Cassandra
Store recent, frequently accessed data with low latency and high availability
Why thisCassandra supports linear write scalability, tunable consistency, and TTL for auto-expiry
Why notPostgreSQL rejected due to complex manual sharding and write bottlenecks at 1M+ QPS
Warm Tier - Cassandra
Store less frequently accessed data with moderate latency and cost
Why thisSame tech as hot tier but with fewer replicas and larger compaction windows to reduce cost
Why notElasticsearch rejected due to high resource usage and slower writes at scale
Cold Tier - HDFS + HBase
Store large volumes of older data with high latency tolerance and batch access
Why thisHDFS provides scalable distributed storage; HBase enables random reads with acceptable latency
Why notS3 standard rejected due to higher cost and slower random read performance
Archive Tier - Amazon S3 Glacier
Long-term offline storage with minimal cost and batch retrieval
Why thisGlacier offers lowest cost for infrequently accessed data with retrieval delays acceptable for archive
Why notCold HDD storage rejected due to lack of integration and durability guarantees
Lifecycle Manager
Automates data migration between tiers based on policies and access patterns
Why thisBatch jobs with Apache Airflow orchestrate tier transitions reliably and scalably
Why notManual scripts rejected due to error-prone operations and lack of auditability
🔄
Data Flow
1
Client API → Tiering Controller
Receive write request with data and metadata
Client unaware of tiering; sends data uniformly
2
Tiering Controller → Hot Tier (Cassandra)
Route write to hot tier for low latency storage
Hot tier stores data with TTL for automatic expiry

Practice

(1/5)
1. For a CDN serving frequently updated dynamic content, which origin content delivery strategy is best to ensure freshness without overloading the origin server?
medium
A. Pull model where edge nodes fetch content from origin on cache miss with TTL-based caching
B. Push model where origin proactively sends all content updates to edge nodes
C. Push model with edge nodes polling origin periodically for updates
D. Pull model with edge nodes never caching content and always fetching from origin

Solution

  1. Step 1: Analyze push vs pull for dynamic content freshness

    Push model can overload origin with frequent updates; polling adds unnecessary load.

  2. Step 2: Evaluate pull with TTL caching

    Pull with TTL balances freshness and origin load by caching briefly and refreshing on expiry.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Pull with TTL caching balances freshness and origin load [check]
Hint: Pull with TTL balances freshness and load [check]
Common Mistakes:
2. If the Kafka cluster responsible for fan-out message delivery crashes, what is the exact failure observed in the News Feed system?
medium
A. New posts are lost permanently and never delivered to followers
B. The system blocks new post writes until Kafka recovers, causing user-facing delays
C. Followers receive duplicate feed updates due to Kafka replaying messages
D. Delivery Workers cannot fetch fan-out messages, so followers see stale feeds until recovery

Solution

  1. Step 1: Understand Kafka's role in fan-out delivery

    Kafka acts as a durable queue for fan-out messages. If it crashes, Delivery Workers cannot fetch new messages, causing stale feeds.

  2. Step 2: Evaluate failure modes

    Posts are not lost immediately (A) due to Kafka's durability; writes are asynchronous so no blocking (B); duplicates (D) occur only on replay, not crash.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Kafka crash stalls delivery, causing stale feeds [check]
Hint: Kafka crash stalls delivery, causing stale feeds [check]
Common Mistakes:
3. For a chat system requiring low latency and fault tolerance, which architecture is best when mobile clients have intermittent connectivity?
medium
A. Use gRPC streaming for persistent connections to push messages instantly
B. Use a message queue with client-side polling and exponential backoff
C. Use WebSocket connections with server-side buffering and reconnection logic
D. Use HTTP long polling with immediate retries on failure

Solution

  1. Step 1: Evaluate client connectivity constraints

    Mobile clients have intermittent connectivity; gRPC streaming (A) requires persistent connections, which mobile networks may not support well. HTTP long polling (D) causes overhead and latency.

  2. Step 2: Compare WebSocket with server buffering vs polling

    WebSocket with server-side buffering and reconnection (C) balances low latency and fault tolerance better than client polling (B), which increases latency and load.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    WebSocket + buffering + reconnection -> best for intermittent mobile [check]
Hint: WebSocket buffers and reconnects for flaky mobile networks [check]
Common Mistakes:
4. For a system ingesting high-frequency IoT sensor data with strict latency requirements, which architecture is better and why?
medium
A. Stream processing with windowed aggregations to provide near real-time metrics
B. Batch processing with hourly aggregation jobs to reduce storage load
C. Storing raw data only and running ad-hoc queries on demand
D. Using a relational database with indexing on timestamp for query speed

Solution

  1. Step 1: Analyze latency and ingestion frequency requirements

    High-frequency data with strict latency requires near real-time processing to avoid stale metrics.

  2. Step 2: Compare architectures

    Batch processing (A) introduces high latency unsuitable for real-time needs. Storing raw data only (C) delays insights and burdens query engines. Relational DBs (D) struggle with high write throughput and time-series data volume. Stream processing (B) supports continuous, low-latency windowed aggregations.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Stream processing enables low-latency, continuous aggregation [check]
Hint: Stream processing fits low-latency, high-frequency IoT data [check]
Common Mistakes:
5. If the CDN's cache invalidation mechanism fails to propagate updates, what is the exact failure experienced by end users?
medium
A. Users get 404 errors because the CDN deletes cached content prematurely
B. Users receive outdated content until cache TTL expires, causing stale data display
C. Origin servers become overloaded as CDN stops serving any cached content
D. Users experience increased latency due to CDN routing loops

Solution

  1. Step 1: Understand cache invalidation failure impact

    Failure to propagate invalidation means cached content remains stale beyond intended update.

  2. Step 2: Identify user experience as stale content served until TTL expiry

    Users see outdated data until cache naturally expires or is manually cleared.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Cache invalidation failure -> stale content served, not errors or overload [check]
Hint: Invalidation fails -> stale content served until TTL expires [OK]
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