Bird
Raised Fist0

Design a URL Shortener - Encoding, Redirect, Analytics, Custom Alias

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

Receive URL shortening request with custom alias

Client sends POST /shorten with original URL and alias

Protocol:HTTP POST
BeforeNo URL mapping exists for the alias
AfterRequest forwarded to Write Service for processing
Write Service

Validate and store URL + alias mapping

Write Service writes mapping to Cassandra Cluster

Protocol:Cassandra write
BeforeAlias not stored in Cassandra Cluster
AfterAlias and URL durably stored in Cassandra Cluster
API Gateway

Receive redirect request for alias

Client sends GET /{alias} to redirect

Protocol:HTTP GET
BeforeAlias exists in Cassandra Cluster but not cached
AfterRequest forwarded to Read Service
Read Service

Lookup alias in Redis Cache

Read Service queries Redis for cached URL

Protocol:Redis GET
BeforeCache may or may not contain alias
AfterCache miss triggers Cassandra Cluster read or cache hit returns URL
Read Service

Redirect client and produce analytics event

Send HTTP 302 redirect and produce event to Kafka Analytics

Protocol:HTTP 302 + Kafka produce
BeforeURL resolved from cache or DB
AfterClient redirected; analytics event queued in Kafka Analytics
Kafka Analytics

Queue analytics event

Kafka Analytics stores redirect event for processing

Protocol:Kafka internal
BeforeNo analytics event for this redirect
AfterEvent durably stored in Kafka Analytics topic
Analytics DB

Consume and store analytics data

Analytics consumer reads from Kafka Analytics and writes to DB

Protocol:Kafka consume + DB write
BeforeAnalytics event in Kafka Analytics topic
AfterEvent persisted in Analytics DB for reporting
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │ HTTP POST /shorten (custom alias)
        ▼
┌───────────────┐
│ Write Service │
└───────┬───────┘
        │ Cassandra Cluster write (URL + alias)
        ▼
┌───────────────┐
│ Cassandra     │
│ Cluster       │
└───────┬───────┘
        │ Write ack
        ▼
┌───────────────┐
│ API Gateway   │
└───────┬───────┘
        │ HTTP GET /{alias} (redirect request)
        ▼
┌───────────────┐
│ Read Service  │
└───────┬───────┘
        │ Redis GET (cache lookup)
        ▼
┌───────────────┐
│ Redis Cache   │
└───────┬───────┘
        │ Cache miss or hit
        ▼
┌───────────────┐
│ Cassandra     │
│ Cluster       │
└───────┬───────┘
        │ URL returned
        ▼
┌───────────────┐
│ Read Service  │
└───────┬───────┘
        │ Redirect HTTP 302
        │ Kafka Analytics produce (analytics event)
        ▼
┌───────────────┐
│ Kafka         │
│ Analytics     │
└───────┬───────┘
        │ Consume events
        ▼
┌───────────────┐
│ Analytics DB  │
└───────────────┘
Design Rationale

This URL Shortener architecture uses an API Gateway as the single entry point for all client requests. The Write Service handles URL shortening requests, validating and storing the original URL and custom alias in Cassandra, which provides durable storage. For redirects, the Read Service first checks Redis Cache for a fast lookup; on cache miss, it queries Cassandra. After resolving the URL, the Read Service issues an HTTP 302 redirect to the client and produces an analytics event to Kafka. Kafka acts as a durable event queue, decoupling analytics processing from request latency. Analytics consumers read from Kafka and persist data in the Analytics DB for reporting. This design balances low-latency redirects with durable storage and scalable analytics.

Primary Focus

✓

Practice

(1/5)
1. If the rollback mechanism is missing in the deployment system, what exact failure occurs when a faulty version is released during Canary deployment?
medium
A. Users experience degraded service indefinitely as faulty version remains live without fallback
B. The previous stable version is restored manually without affecting users
C. The deployment system retries indefinitely, causing deployment pipeline blockage
D. The system automatically disables all new features, causing partial outages

Solution

  1. Step 1: Understand rollback absence impact

    Without rollback, faulty Canary version cannot be reverted automatically.

  2. Step 2: Trace failure effect

    Faulty version remains live, causing degraded user experience indefinitely.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    No rollback -> faulty version stays live -> degraded service persists [check]
Hint: No rollback means faulty version stays live, degrading users indefinitely [OK]
Common Mistakes:
2. If the OT engine component crashes and loses its in-memory operation buffer before persisting, what is the most likely failure observed by users during collaborative editing?
medium
A. The document becomes read-only until the OT engine restarts
B. Users' concurrent edits are lost or cause inconsistent document states without recovery
C. Users see duplicate edits because operations are replayed multiple times
D. Users experience delayed edits but no data loss due to persistent storage

Solution

  1. Step 1: Identify OT engine's role in buffering and transforming operations

    The OT engine buffers concurrent operations in memory to transform and order them before persistence.

  2. Step 2: Trace failure impact of OT engine crash losing in-memory buffer

    Without the buffer, the engine cannot process new edits correctly, causing the system to block new edits (read-only) until recovery.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    OT engine crash causes editing to block (read-only), not silent data loss [check]
Hint: OT engine crash blocks edits; no silent data loss [check]
Common Mistakes:
3. For a faceted search system with frequent filter updates and millions of documents, which architecture better balances update latency and query freshness?
medium
A. Use a near-real-time indexing system that streams document changes to shards asynchronously
B. Use a batch indexing pipeline that rebuilds the entire inverted index every hour
C. Use a write-through cache that updates inverted indexes synchronously on every document change
D. Use a static precomputed index refreshed monthly with manual invalidation

Solution

  1. Step 1: Compare update latency and query freshness trade-offs

    Batch rebuilds have high latency; synchronous writes hurt write throughput; static monthly refresh is too stale.

  2. Step 2: Identify near-real-time indexing benefits

    Streaming updates asynchronously balances freshness and throughput, allowing queries to see recent changes with low delay.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Near-real-time streaming -> balanced freshness and update latency [check]
Hint: Near-real-time streaming balances freshness and throughput [check]
Common Mistakes:
4. For a mobile app requiring real-time notifications at 10x scale, which architecture is better and why?
medium
A. Use WebSockets with a scalable connection broker to handle mobile client limitations
B. Use gRPC streaming for persistent connections to push notifications
C. Use long polling HTTP requests to simulate real-time updates
D. Use periodic polling every 5 seconds to reduce server load

Solution

  1. Step 1: Evaluate mobile client support

    gRPC streaming (Use gRPC streaming for persistent connections to push notifications) is efficient but poorly supported on many mobile platforms, causing compatibility issues.

  2. Step 2: WebSockets with connection broker

    WebSockets (Use WebSockets with a scalable connection broker to handle mobile client limitations) are widely supported on mobile and, with a scalable broker, can handle millions of connections efficiently.

  3. Step 3: Polling drawbacks

    Long polling (Use long polling HTTP requests to simulate real-time updates) and periodic polling (Use periodic polling every 5 seconds to reduce server load) increase latency and server load, unsuitable for real-time at scale.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    WebSockets + broker -> scalable, mobile-friendly real-time [check]
Hint: WebSockets scale better on mobile than gRPC streaming [OK]
Common Mistakes:
5. At 10x scale, which component in the API Gateway + BFF architecture is most likely to become the first bottleneck, and why?
hard
A. Microservices database, due to increased write contention
B. API Gateway, because it must maintain stateful WebSocket connections for all clients
C. BFF layer, as it performs CPU-intensive aggregation and transformation per request
D. Load balancer, due to limited connection handling capacity

Solution

  1. Step 1: Identify component workload at scale

    BFF performs CPU-intensive aggregation and transformation per request, which grows linearly with client requests.

  2. Step 2: Compare other components

    Microservices database, due to increased write contention is less likely first bottleneck as databases can be scaled horizontally or partitioned. API Gateway, because it must maintain stateful WebSocket connections for all clients is incorrect because API Gateway is typically stateless or uses connection offloading. Load balancer, due to limited connection handling capacity is wrong since load balancers scale well horizontally.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    BFF CPU-bound aggregation limits scale before other components [check]
Hint: BFF CPU-bound aggregation limits scale before others [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