Bird
Raised Fist0

Blob Store Design - S3-Like Object Storage Architecture End to End

HLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/5
API Gateway

Receive multipart upload initiation request

Client sends POST to start multipart upload session

Protocol:HTTPS
BeforeNo multipart upload session exists for this object
AfterAPI Gateway forwards initiation request to Multipart Upload Coordinator
Multipart Upload Coordinator

Create multipart upload session metadata

Coordinator requests Metadata Store to create upload record

Protocol:RPC
BeforeNo upload session metadata exists in Metadata Store
AfterMetadata Store has new upload session record with unique upload ID
Storage Nodes

Store uploaded part data

Client uploads part directly to Storage Nodes via coordinator instructions

Protocol:HTTP PUT
BeforeStorage Nodes do not have this part data
AfterStorage Nodes store part data and verify checksum
Multipart Upload Coordinator

Update metadata with uploaded part info

Coordinator updates Metadata Store with part number and ETag

Protocol:RPC
BeforeMetadata Store lacks info about this uploaded part
AfterMetadata Store records part info linked to upload session
Replication Service

Replicate stored part asynchronously

Replication Service pulls part from Storage Nodes to replicate

Protocol:Internal replication protocol
BeforePart exists only on primary Storage Node
AfterPart replicated to secondary Storage Nodes for durability
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────┐
│    API Gateway    │
│  (REST API front) │
└─────────┬─────────┘
          │ HTTPS POST /multipart/initiate
          ▼
┌───────────────────────────────┐
│ Multipart Upload Coord.       │
│ (manages upload sessions)     │
└─────────────┬─────────────────┘
              │ RPC to Metadata Store: create upload record
              ▼
       ┌───────────────────┐
       │  Metadata Store   │
       │ (stores metadata) │
       └─────────┬─────────┘
                 │ Metadata record created
                 ▼
┌───────────────────────────────┐
│ Multipart Upload Coord.       │
│ (coordinates part uploads)    │
└─────────────┬─────────────────┘
              │ Direct PUT part to Storage Nodes (HTTP)
              ▼
       ┌───────────────────┐
       │  Storage Nodes    │
       │ (store object data)│
       └─────────┬─────────┘
                 │ Part stored and checksum verified
                 ▼
┌───────────────────────────────┐
│ Multipart Upload Coord.       │
│ (tracks uploaded parts)       │
└─────────────┬─────────────────┘
              │ Update Metadata Store with part info (RPC)
              ▼
       ┌───────────────────┐
       │  Metadata Store   │
       │ (update part info)│
       └─────────┬─────────┘
                 │ Metadata updated
                 ▼
┌───────────────────────────────┐
│ Replication Service            │
│ (replicates parts asynchronously)│
└───────────────────────────────┘
Design Rationale

This S3-like blob store architecture uses an API Gateway as the entry point for client requests. The Multipart Upload Coordinator manages multipart upload sessions, coordinating with the Metadata Store to persist upload metadata. Clients upload parts directly to Storage Nodes, which store the data and verify integrity. The coordinator updates the Metadata Store with part details after each upload. Meanwhile, the Replication Service asynchronously replicates stored parts across nodes to ensure durability and availability. This vertical flow ensures separation of concerns: API Gateway handles client interaction, Metadata Store manages metadata consistency, Storage Nodes handle data persistence, and Replication Service guarantees fault tolerance.

Primary Focus

✓

Practice

(1/5)
1. A system must handle 1 million writes per second and fan-out to millions of users asynchronously. Which component best handles decoupling write load from delivery?
easy
A. Use direct HTTP calls from sender to all receivers to guarantee delivery order
B. Use a relational database with sharded writes to handle all writes and fan-out synchronously
C. Use an in-memory cache like Redis to store all messages and fan-out immediately
D. Use a distributed message queue like Kafka to buffer writes and enable asynchronous fan-out

Solution

  1. Step 1: Identify the need for decoupling writes from fan-out

    Handling 1 million writes per second with synchronous fan-out is not feasible on a single machine or direct calls.

  2. Step 2: Evaluate components for asynchronous buffering

    Kafka provides durable, partitioned logs that buffer writes and allow scalable asynchronous delivery. Relational DBs can't handle this write load synchronously. Redis lacks durability guarantees for this scale. Direct HTTP calls block and don't scale.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Kafka buffers writes asynchronously, enabling high write throughput [check]
Hint: Use durable queues to decouple high write load [check]
Common Mistakes:
2. If the Feature Store's update stream (e.g., Kafka) fails, what exactly breaks in the search ranking system?
medium
A. Model Serving continues scoring with stale features, causing degraded ranking quality
B. Feature Store blocks all read requests until the update stream recovers, causing high latency
C. A/B testing traffic routing fails, causing all users to see the control model only
D. The system loses all feature data permanently, causing model serving to crash

Solution

  1. Step 1: Trace failure impact of update stream loss

    The update stream failure stops feature updates but does not block reads or cause permanent data loss.

  2. Step 2: Identify component relying on update stream

    A/B testing routing depends on fresh feature updates to decide traffic splits; without updates, routing falls back to control model only.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Update stream failure -> A/B routing fallback to control model [check]
Hint: Update stream failure -> A/B routing falls back, not feature reads [check]
Common Mistakes:
3. For a real-time multiplayer game backend requiring low latency and consistent player state, which architecture is more appropriate and why?
medium
A. Stateful servers storing player state only in a distributed cache without persistence
B. Stateless microservices with external database for player state
C. Stateless servers with client-side state management and server validation
D. Stateful game servers maintaining player state in memory with periodic persistence

Solution

  1. Step 1: Analyze latency and consistency needs

    Real-time games require fast access to player state with strong consistency.

  2. Step 2: Evaluate architecture trade-offs

    Stateful servers with in-memory state reduce latency and allow immediate state updates; periodic persistence balances durability.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Stateful in-memory state + persistence -> low latency, consistent [check]
Hint: In-memory stateful servers best for real-time consistency [check]
Common Mistakes:
4. If the Ticket Server crashes after allocating an ID block but before the client acknowledges, what is the exact failure observed in the system?
medium
A. Clients receive duplicate IDs because the block is reissued without tracking
B. Some ID blocks are lost, causing gaps in the global ID sequence but no duplicates
C. Clients block indefinitely waiting for the Ticket Server response, halting ID generation
D. Clients generate IDs locally without coordination, risking collisions

Solution

  1. Step 1: Understand Ticket Server crash impact

    If the server crashes post-allocation but pre-acknowledgment, it cannot confirm the block was assigned.

  2. Step 2: Trace ID block state

    The allocated block is effectively lost, causing gaps in the global ID sequence, but clients do not reuse lost blocks, preventing duplicates.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Crash after allocation -> lost ID blocks, no duplicates [check]
Hint: Crash post-allocation loses blocks, no duplicate IDs generated [check]
Common Mistakes:
5. At 10x scale, which component in a microservices architecture is most likely to become the first bottleneck, and why?
hard
A. The shared database, because it cannot be sharded easily without complex coordination
B. The individual microservices, because their stateful WebSocket connections limit horizontal scaling
C. The service discovery system, because it must track exponentially more services and instances
D. The API Gateway, because it handles all incoming requests and becomes a centralized choke point

Solution

  1. Step 1: Identify stateful components at risk

    Stateful microservices holding WebSocket connections cannot easily shard or move connections, limiting horizontal scaling.

  2. Step 2: Compare other components' scaling characteristics

    Shared DB and service discovery can be sharded or cached; API Gateway can be scaled horizontally with load balancers.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Stateful WebSocket connections limit microservices horizontal scaling [check]
Hint: Stateful WebSocket limits microservices scaling first [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