Bird
Raised Fist0

Design Pastebin - Text Storage, Expiration, Analytics

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

Receives new paste submission

Accepts HTTP POST with paste text and expiration metadata

Protocol:HTTP REST
BeforeUser has paste text ready to submit
AfterPaste request forwarded to Write Service
Write Service

Processes paste and publishes event

Stores paste metadata and produces event to Kafka Topic

Protocol:Kafka Produce
BeforePaste request received from API Gateway
AfterPaste event durably stored in Kafka Topic
Kafka Topic

Queues paste write event

Holds paste event for consumption by storage service

Protocol:Kafka Consume
BeforePaste event produced by Write Service
AfterPaste event ready for Cassandra DB consumer
Cassandra DB

Stores paste text and metadata

Writes paste data with expiration timestamp

Protocol:CQL Write
BeforePaste event consumed from Kafka Topic
AfterPaste data durably stored in Cassandra DB
Cache Layer (Redis Cluster)

Caches paste data with TTL

Sets paste text in Redis with expiration TTL

Protocol:Redis SET
BeforePaste data stored in Cassandra DB
AfterPaste available in Redis cache for fast reads
Read Service

Serves paste read requests

Checks Redis cache first, falls back to Cassandra if miss

Protocol:HTTP GET
BeforeUser requests paste retrieval
AfterPaste text returned to user from cache or DB
Expiration Worker

Deletes expired pastes and updates analytics

Scans Cassandra for expired pastes, deletes them, logs stats

Protocol:Batch Query
BeforeExpired pastes exist in Cassandra DB
AfterExpired pastes removed; analytics updated in ClickHouse
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │ HTTP POST (REST)
        ▼
┌───────────────┐
│ Write Service │
└───────┬───────┘
        │ Kafka Produce
        ▼
┌───────────────┐
│ Kafka Topic   │
└───────┬───────┘
        │ Kafka Consume
        ▼
┌───────────────┐
│ Cassandra DB  │
└───────┬───────┘
        │ Redis SET (Cache)
        ▼
┌────────────────────────┐
│ Cache Layer (Redis Cl.)│
└───────┬────────────────┘
        │ HTTP GET (REST)
        ▼
┌───────────────┐
│ Read Service  │
└───────┬───────┘
        │ Query
        ▼
┌───────────────┐
│ Analytics DB  │
│ (ClickHouse)  │
└───────┬───────┘
        │ Periodic Batch
        ▼
┌────────────────┐
│ Expiration     │
│ Worker         │
└────────────────┘
Design Rationale

This architecture for Design Pastebin shows a vertical flow from client submission to storage, caching, reading, and expiration. The API Gateway receives paste submissions and forwards them to the Write Service, which publishes events to a Kafka Topic for durability and decoupling. The Kafka Topic feeds the Cassandra DB, the primary durable store for paste text and metadata. After storage, the paste is cached in Redis with a TTL for fast reads. The Read Service serves user read requests by querying Redis first, falling back to Cassandra on cache misses. The Expiration Worker runs asynchronously, scanning Cassandra for expired pastes to delete and updating usage analytics in ClickHouse. This design balances durability, read performance, and background cleanup with clear separation of concerns and asynchronous event-driven processing.

Primary Focus

✓

Practice

(1/5)
1. A distributed key-value store must remain operational during network partitions but can tolerate stale reads temporarily. Which system design choice best supports this requirement?
easy
A. Use a CP system that blocks writes during partitions to maintain consistency
B. Use a CA system that rejects requests during partitions to maintain availability and consistency
C. Use a synchronous replication system that waits for all replicas before responding
D. Use an AP system that serves reads and writes with eventual consistency during partitions

Solution

  1. Step 1: Identify CAP constraints

    During network partitions, a system must choose between consistency and availability.

  2. Step 2: Match system behavior

    AP systems prioritize availability and partition tolerance, allowing stale reads but remaining operational.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    AP systems allow availability during partitions with eventual consistency [check]
Hint: AP favors availability over consistency during partitions [check]
Common Mistakes:
2. A web service requires encrypted communication with client browsers but must minimize CPU overhead on the server. Which component primarily handles the encryption and decryption workload during connection setup?
easy
A. The TLS handshake process managed by the server's SSL/TLS library
B. The client browser encrypting data before sending HTTP requests
C. The web application server performing manual encryption of HTTP payloads
D. The DNS server resolving domain names to IP addresses

Solution

  1. Step 1: Identify TLS handshake role

    The TLS handshake is responsible for negotiating encryption parameters and performing cryptographic operations to secure the connection.

  2. Step 2: Eliminate other options

    The web application server performing manual encryption of HTTP payloads is incorrect because manual encryption by the app server is inefficient and not standard. The client browser encrypting data before sending HTTP requests is incorrect because the client does not perform the handshake encryption workload; it participates but the server's TLS library handles the cryptographic operations. The DNS server resolving domain names to IP addresses is unrelated to encryption.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    TLS handshake handles encryption setup on server side [check]
Hint: TLS handshake manages encryption setup on server side [check]
Common Mistakes:
3. A web API must limit incoming requests to 100 per second with bursts allowed up to 200 requests. Which component best enforces this rate limiting with burst handling?
easy
A. A fixed window counter that resets every second
B. A simple request queue that drops requests when full
C. A leaky bucket algorithm that processes requests at a fixed rate without bursts
D. A token bucket algorithm that refills tokens at a steady rate with a maximum bucket size

Solution

  1. Step 1: Identify rate limiting with burst support

    The token bucket algorithm allows tokens to accumulate up to a max bucket size, enabling bursts beyond the steady refill rate.

  2. Step 2: Eliminate other options

    Fixed window counters cause spikes at window boundaries and don't handle bursts well. Leaky bucket smooths traffic but disallows bursts. Simple queues drop excess requests without rate control.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Token bucket allows bursts by token accumulation [check]
Hint: Token bucket = steady refill + burst capacity [OK]
Common Mistakes:
4. If the Dead Letter Queue component is removed from the system, what is the most likely failure scenario when a message processing fails repeatedly?
medium
A. The main queue blocks processing as failed messages are retried indefinitely, causing backpressure
B. The system switches to synchronous processing, increasing latency but ensuring delivery
C. Messages are automatically routed to a backup queue with no delay
D. Messages are silently dropped without any retry or alerting

Solution

  1. Step 1: Understand DLQ role in failure isolation

    Without DLQ, failed messages remain in the main queue causing retries that block subsequent messages.

  2. Step 2: Evaluate failure outcomes

    Silent drops (A) lose data; automatic routing (C) requires DLQ logic; synchronous fallback (D) is not automatic.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    No DLQ -> retries block main queue causing backpressure [check]
Hint: No DLQ means retries block main queue, causing backpressure [OK]
Common Mistakes:
5. At 10x scale, which component in a circuit breaker-enabled microservice architecture is most likely to fail first, and why?
hard
A. The downstream service, because it cannot handle increased request volume despite circuit breaker protection
B. The circuit breaker state store, because centralized state tracking causes contention and latency under high concurrency
C. The load balancer, because it cannot distribute 10x more connections evenly
D. The client-side cache, because it grows too large and causes memory pressure

Solution

  1. Step 1: Analyze scaling impact on components

    Downstream service (A) is protected by circuit breaker; load balancer (C) scales horizontally; client cache (D) is local and less critical.

  2. Step 2: Identify circuit breaker state store bottleneck

    Centralized state store for circuit breaker metrics faces contention and latency at 10x concurrency, causing delays and incorrect breaker states.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Centralized circuit breaker state store bottlenecks first at scale [check]
Hint: Centralized circuit breaker state store bottlenecks first at scale [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