Bird
Raised Fist0

ULID and KSUID - Sortable Distributed IDs for Modern Systems

HLDmediumInterview freq: medium
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
ID Generation Service

Receives client request for new ID

Client sends HTTP request to generate a new sortable ID

Protocol:HTTP/REST API
BeforeNo ID generated for this request yet
AfterRequest accepted and processing started
ID Generation Service

Calls ID Generation Library

Requests ULID or KSUID generation internally

Protocol:Internal API Call
BeforeRequest received, no ID generated
AfterSortable ID generated by library
ID Generation Library

Generates ULID or KSUID

Creates a time-sortable unique identifier

Protocol:Library function call
BeforeNo ID generated for this request
AfterSortable distributed ID created and returned
Kafka (Apache Kafka)

Receives produced ID event

ID Generation Service publishes ID event to Kafka topic

Protocol:Kafka Produce
BeforeID generated but not durably stored
AfterID event durably stored in Kafka partition
Storage Cluster (Cassandra/Scylla)

Consumes Kafka event and stores ID

Writes generated ID to distributed storage for queries

Protocol:Cassandra Write
BeforeID event in Kafka, not yet in DB
AfterID persisted in storage cluster, queryable
Monitoring & Alerting

Collects metrics and logs

Monitors ID Generation Service and Kafka health

Protocol:Metrics & Logs
BeforeSystem running, no alerts
AfterMetrics updated, alerts triggered if anomalies
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────────────┐
│       Client Request           │
└───────────────┬───────────────┘
                │ HTTP/REST API
                ▼
┌───────────────────────────────┐
│   ID Generation Service       │
│  - Receives ID requests       │
│  - Calls ID Generation Library│
└───────────────┬───────────────┘
                │ Internal API Call
                ▼
┌───────────────────────────────┐
│    ID Generation Library      │
│  - Generates ULID or KSUID    │
│  - Returns sortable ID        │
└───────────────┬───────────────┘
                │ Kafka Produce
                ▼
┌───────────────────────────────┐
│    Kafka (Apache Kafka)       │
│  - Durable event queue        │
│  - Partitioned by ID type     │
└───────────────┬───────────────┘
                │ Cassandra Write
                ▼
┌───────────────────────────────┐
│ Storage Cluster (Cassandra/Scylla)│
│ - Stores generated IDs       │
│ - Supports fast range queries│
└───────────────┬───────────────┘
                │ Metrics & Logs
                ▼
┌───────────────────────────────┐
│ Monitoring & Alerting         │
│ - Tracks service health      │
│ - Alerts on anomalies        │
└───────────────────────────────┘
Design Rationale

This architecture shows a vertically layered flow for generating ULID or KSUID distributed IDs. The client sends a request to the ID Generation Service, which calls the ID Generation Library to produce a time-sortable unique ID. This ID is then published as an event to Kafka, ensuring durability and ordering. A storage cluster like Cassandra consumes Kafka events and persists the IDs for fast range queries. Monitoring & Alerting continuously track system health and performance. The vertical flow emphasizes separation of concerns and durability guarantees, with Kafka acting as a reliable event buffer between generation and storage.

Primary Focus

✓

Practice

(1/5)
1. A real-time analytics system must ingest 1 million events per second and provide near-instant query results. Which component best handles the ingestion to balance latency and throughput?
easy
A. A relational database with strong consistency guarantees
B. A batch processing system that aggregates events every minute
C. A distributed log system like Apache Kafka with partitioned topics
D. A single-threaded in-memory queue to ensure ordering

Solution

  1. Step 1: Identify ingestion requirements

    High throughput and low latency ingestion require a scalable, partitioned system that can handle parallel writes.

  2. Step 2: Evaluate components

    Relational DBs (A) can't handle this write volume with low latency; single-threaded queues (C) limit throughput; batch systems (D) increase latency.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Kafka partitions enable parallel ingestion with low latency [check]
Hint: Partitioned logs scale writes and keep latency low [check]
Common Mistakes:
2. In a token bucket rate limiter, at step 4 the Request Handler checks the token count before processing a request. What happens if the bucket is empty at this step?
easy
A. The token count is reset to maximum and the request proceeds
B. The request is immediately processed and the token count goes negative
C. The request is rejected or delayed until tokens are refilled
D. The request is queued indefinitely without token consumption

Solution

  1. Step 1: Trace Request Handler token check at Step 4

    If the token bucket is empty, no tokens are available to allow immediate processing.

  2. Step 2: Determine request fate

    The request must be rejected or delayed until tokens refill; processing without tokens violates rate limits.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Empty bucket -> reject or delay request [check]
Hint: No tokens? Delay or reject request [OK]
Common Mistakes:
3. In a system using Zookeeper for leader election, at step 4 in the request trace, the follower node receives a notification that the leader's ephemeral node has disappeared. What state change does the follower node perform at this step?
easy
A. The follower node attempts to create a new ephemeral node to become leader
B. The follower node restarts its local cache without leader election
C. The follower node ignores the event and continues as follower
D. The follower node immediately assumes leadership without coordination

Solution

  1. Step 1: Understand Zookeeper ephemeral node disappearance

    Leader's ephemeral node disappearance signals leader failure.

  2. Step 2: Follower reaction

    Follower tries to create ephemeral node to become new leader; immediate assumption without coordination risks split-brain.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Follower creates ephemeral node -> attempts leadership [check]
Hint: Ephemeral node gone -> followers try to create leader node [check]
Common Mistakes:
4. If Kafka is unavailable, what exactly breaks in the tweet delivery pipeline?
medium
A. Tweets are stored in the DB but timeline caches become permanently stale
B. Tweets are lost immediately with no retry and followers see no updates
C. Tweet ingestion blocks; fan-out delivery waits synchronously causing user write latency spikes
D. Delivery workers switch to synchronous RPC calls causing partial delivery and blocking

Solution

  1. Step 1: Role of Kafka in delivery pipeline

    Kafka buffers tweets asynchronously for fan-out; unavailability stops new fan-out events.

  2. Step 2: Trace failure impact

    Tweets still persist in DB, but without Kafka, timeline caches don't get updated, causing stale timelines.

  3. Step 3: Eliminate other options

    Immediate loss (A) is prevented by DB persistence; ingestion blocking (B) unlikely as writes decouple; synchronous RPC fallback (D) not implemented.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    Kafka outage stalls fan-out, causing stale timeline caches [check]
Hint: Kafka outage stalls fan-out, stale timelines appear [check]
Common Mistakes:
5. At 10x scale, which component in your 45-minute system design answer is most likely to fail first, and why?
hard
A. The caching layer because it always becomes stale at scale
B. The load balancer because it cannot distribute traffic evenly at high scale
C. The database because it cannot handle increased query volume without sharding
D. The stateful session management because it binds user sessions to specific servers limiting horizontal scaling

Solution

  1. Step 1: Identify stateful session management bottleneck

    Stateful sessions bind users to servers, preventing easy horizontal scaling and causing failure under 10x load.

  2. Step 2: Exclude other components that scale better or have mitigation

    Databases can shard; load balancers scale horizontally; caches can be invalidated or refreshed.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Stateful sessions limit scaling -> first failure point [check]
Hint: Stateful sessions block 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