Storage access patterns in HLD - System Design Exercise

Design: Storage Access Patterns Design

Design focuses on common storage access patterns and their architectural implications. Does not cover specific database engine internals or hardware-level optimizations.

Functional Requirements

FR1: Support efficient data retrieval for different use cases

FR2: Handle both read-heavy and write-heavy workloads

FR3: Provide low latency access to frequently used data

FR4: Ensure data consistency and durability

FR5: Support batch and real-time data processing

Non-Functional Requirements

NFR1: System should handle up to 100,000 concurrent requests

NFR2: Average read latency should be under 50ms

NFR3: Availability target of 99.9% uptime

NFR4: Data size can grow to multiple terabytes

NFR5: Support horizontal scaling

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Cache layer (e.g., Redis, Memcached)

Primary database (SQL or NoSQL)

Message queues for asynchronous writes

Batch processing systems

API gateway or service layer

Design Patterns

Cache-aside pattern

Read-through and write-through caching

Eventual consistency with asynchronous writes

CQRS (Command Query Responsibility Segregation)

Sharding and partitioning

Bulk loading and batch processing

Reference Architecture

          +-------------+          +-------------+          +-------------+
          |   Clients   | <------> | API Gateway | <------> | Cache Layer |
          +-------------+          +-------------+          +-------------+
                                         |                        |
                                         |                        v
                                         |                 +-------------+
                                         |                 | Primary DB  |
                                         |                 +-------------+
                                         |
                                         v
                                  +----------------+
                                  | Message Queue  |
                                  +----------------+
                                         |
                                         v
                                  +----------------+
                                  | Batch Process  |
                                  +----------------+

Components

Clients

Any client application

Initiate data requests and receive responses

API Gateway

REST/gRPC API server

Handle client requests, route to cache or database

Cache Layer

Redis or Memcached

Store frequently accessed data for low latency reads

Primary DB

Relational (PostgreSQL) or NoSQL (MongoDB)

Persistent storage of data with consistency guarantees

Message Queue

Kafka or RabbitMQ

Buffer write operations for asynchronous processing

Batch Process

Apache Spark or custom batch jobs

Process large volumes of data asynchronously

Request Flow

1. Client sends a read request to API Gateway.

2. API Gateway checks Cache Layer for data.

3. If data is in cache (cache hit), return data to client immediately.

4. If data is not in cache (cache miss), API Gateway queries Primary DB.

5. Primary DB returns data to API Gateway, which updates Cache Layer and responds to client.

6. For write requests, API Gateway writes data to Primary DB and publishes an event to Message Queue.

7. Batch Process consumes events from Message Queue for asynchronous processing or analytics.

Database Schema

Entities depend on application domain but generally include: - Data Entity: stores main data records with unique IDs - Cache Metadata: tracks cache keys and expiration - Event Log: stores write events for asynchronous processing Relationships: - One-to-many between Data Entity and Event Log (each data change produces events) - Cache is a key-value store mapping keys to data snapshots

Scaling Discussion

Bottlenecks

Cache layer can become a bottleneck if not scaled properly

Primary database may face high write or read load

Message queue throughput limits asynchronous processing

Batch processing jobs may take longer with growing data size

Solutions

Use distributed cache clusters with sharding and replication

Scale database vertically or horizontally with read replicas and partitioning

Use high-throughput message queue systems and partition topics

Optimize batch jobs with incremental processing and parallelism

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying questions, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain different storage access patterns and when to use them

Discuss trade-offs between latency, consistency, and scalability

Highlight importance of caching and asynchronous processing

Describe how components interact and data flows through the system

Address scaling challenges and practical solutions

Practice

1. Which storage access pattern reads data in the order it is stored, one piece after another?

easy

A. Sequential access

B. Random access

C. Batch access

D. Streaming access

Solution

1. Step 1: Understand sequential access meaning

   Sequential access means reading data in the exact order it is stored, one after another.

2. Step 2: Compare with other patterns

   Random access reads data in any order, batch access reads groups of data, streaming processes data continuously.

3. Final Answer:

   Sequential access -> Option A

4. Quick Check:

   Sequential = ordered reading [OK]

Hint: Sequential means reading data in stored order [OK]

Common Mistakes:

• Confusing random access with sequential
• Thinking batch means single item reading
• Mixing streaming with batch processing

2. Which of the following is the correct description of random access in storage systems?

easy

A. Data is read in fixed-size batches only

B. Data is accessed only once and then discarded

C. Data is streamed continuously without breaks

D. Data can be read or written at any location without following order

Solution

1. Step 1: Define random access

   Random access allows reading or writing data at any position without following a sequence.

2. Step 2: Eliminate incorrect options

   Batch access reads fixed-size groups, streaming is continuous flow, and discarding after one access is not random access.

3. Final Answer:

   Data can be read or written at any location without following order -> Option D

4. Quick Check:

   Random access = any location access [OK]

Hint: Random means any location, no order needed [OK]

Common Mistakes:

• Confusing batch with random access
• Thinking streaming means random access
• Assuming random access is sequential

3. Consider a system that processes logs by reading 1000 entries at once, then writes results back. Which access pattern best describes this?

medium

A. Random access, because entries are accessed individually

B. Streaming access, because data flows continuously

C. Batch access, because data is processed in groups

D. Sequential access, because logs are read in order

Solution

1. Step 1: Identify processing style

   The system reads 1000 entries at once, meaning it processes data in groups or batches.

2. Step 2: Match with access patterns

   Batch access means handling data in fixed-size groups, streaming is continuous single flow, random is unordered, sequential is one by one.

3. Final Answer:

   Batch access, because data is processed in groups -> Option C

4. Quick Check:

   Batch = group processing [OK]

Hint: Batch means processing data in groups [OK]

Common Mistakes:

• Confusing batch with streaming
• Assuming sequential means batch
• Thinking random access fits batch processing

4. A developer implemented streaming access but notices high latency and data loss. What is the most likely cause?

medium

A. Not handling backpressure in the streaming pipeline

B. Reading data sequentially instead of randomly

C. Using batch processing instead of continuous streaming

D. Accessing data in random order causing delays

Solution

1. Step 1: Understand streaming issues

   Streaming requires managing data flow to avoid overload, called backpressure handling.

2. Step 2: Identify cause of latency and loss

   If backpressure is not handled, data can pile up causing delays and loss.

3. Final Answer:

   Not handling backpressure in the streaming pipeline -> Option A

4. Quick Check:

   Streaming needs backpressure control [OK]

Hint: Streaming needs backpressure handling to avoid loss [OK]

Common Mistakes:

• Confusing batch with streaming
• Ignoring backpressure importance
• Assuming random access causes streaming issues

5. You design a video streaming service that must deliver smooth playback and allow users to jump to any timestamp instantly. Which storage access pattern combination is best?

hard

A. Sequential access for playback and batch access for buffering

B. Streaming access for playback and random access for seeking

C. Batch access for playback and sequential access for seeking

D. Random access for playback and streaming access for buffering

Solution

1. Step 1: Analyze playback needs

   Smooth playback requires continuous data flow, which is streaming access.

2. Step 2: Analyze seeking needs

   Jumping to any timestamp instantly requires random access to data at any position.

3. Step 3: Combine patterns for best design

   Use streaming for continuous playback and random access for quick seeking.

4. Final Answer:

   Streaming access for playback and random access for seeking -> Option B

5. Quick Check:

   Playback = streaming, seeking = random [OK]

Hint: Streaming for play, random for jump [OK]

Common Mistakes:

• Using sequential for seeking which is slow
• Confusing batch with streaming for playback
• Ignoring random access need for seeking