Bird
Raised Fist0

Why Unique ID Generation Is a Non-Trivial System Design Problem

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
Client Service

Sends unique ID generation request

Client initiates request for a new unique ID

Protocol:HTTP
BeforeClient has no unique ID assigned
AfterRequest sent to ID Generation Service
ID Generation Service

Generates candidate ID and requests coordination

Creates a candidate unique ID and asks Coordination Service to lock

Protocol:gRPC
BeforeNo candidate ID reserved
AfterCandidate ID reserved via Coordination Service lock
Coordination Service

Grants distributed lock for candidate ID

Ensures no other service can assign this ID concurrently

Protocol:Internal RPC
BeforeCandidate ID lock not held
AfterLock granted for candidate ID
Storage (Cassandra)

Persists the unique ID with timestamp

Stores the locked ID to durable storage to guarantee uniqueness

Protocol:CQL
BeforeCandidate ID not stored
AfterUnique ID durably stored with timestamp
ID Generation Service

Releases lock and returns ID to client

Unlocks candidate ID and responds with confirmed unique ID

Protocol:gRPC response
BeforeLock held and ID stored
AfterLock released; client receives unique ID
Monitoring & Alerting

Records metrics and alerts on anomalies

Monitors ID generation latency and lock contention

Protocol:Metrics collection
BeforeNo recent metrics for this request
AfterMetrics updated; alerts triggered if thresholds exceeded
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│    Client Service     │
└─────────────┬─────────┘
              │ HTTP Request: Generate ID
              ▼
┌───────────────────────┐
│ ID Generation Service │
└─────────────┬─────────┘
              │ Coordination RPC
              ▼
┌───────────────────────┐
│ Coordination Service  │
└─────────────┬─────────┘
              │ Lock/Lease Coordination
              ▼
┌─────────────────────────┐
│ Storage (Cassandra)     │
└─────────────┬───────────┘
              │ Write ID with timestamp
              ▼
┌─────────────────────────┐
│ Monitoring & Alerting   │
└─────────────────────────┘
Design Rationale

Unique ID generation is complex because it requires coordination to avoid collisions in distributed systems. The Client Service sends a request to the ID Generation Service, which creates a candidate ID but must coordinate with the Coordination Service to acquire a distributed lock. This lock prevents concurrent assignment of the same ID. Once locked, the ID is durably stored in Cassandra to guarantee persistence and uniqueness. After storage, the lock is released and the ID returned to the client. Monitoring & Alerting tracks system health and detects anomalies like lock contention or storage delays. This architecture highlights the challenges of ensuring uniqueness, durability, and availability simultaneously.

Primary Focus

✓

Practice

(1/5)
1. A microservices platform needs to ensure that a failure in one service's database connection pool does not cause cascading failures in other services. Which architectural component best isolates this failure?
easy
A. Implement bulkheads by partitioning resources per service to isolate failures
B. Use a global circuit breaker shared across all services to stop requests on failure
C. Rely on a centralized load balancer to reroute traffic away from failing services
D. Use a distributed cache to reduce load on the database and prevent failures

Solution

  1. Step 1: Identify failure isolation mechanism

    Global circuit breakers (A) affect all services, causing blast radius expansion. Centralized load balancers (C) reroute but don't isolate resource exhaustion. Distributed cache (D) reduces load but doesn't isolate failures.

  2. Step 2: Understand bulkhead pattern role

    Bulkheads partition resources (e.g., connection pools) per service, preventing one service's failure from impacting others.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Bulkheads isolate failures by resource partitioning [check]
Hint: Bulkheads isolate failures by resource partitioning [check]
Common Mistakes:
2. A web service receives highly variable traffic with some clients opening many simultaneous connections, while others open few. Which load balancing algorithm best distributes load evenly across servers?
easy
A. Round Robin, because it cycles through servers regardless of connection count
B. Weighted Round Robin, because it assigns requests based on server weights only
C. IP Hash, because it ensures requests from the same client always go to the same server
D. Least Connections, because it directs new requests to the server with the fewest active connections

Solution

  1. Step 1: Understand traffic variability

    Clients open varying numbers of connections, so servers can become unevenly loaded if requests are assigned blindly.

  2. Step 2: Evaluate load balancing algorithms

    Round Robin ignores current load, IP Hash pins clients to servers (may cause imbalance), Weighted Round Robin uses static weights ignoring dynamic load. Least Connections dynamically balances based on active connections.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Least Connections adapts to real-time load, balancing uneven client connections [check]
Hint: Least Connections adapts to active load, not just request count [check]
Common Mistakes:
3. If Kafka's offset commit mechanism is disabled, what failure occurs when a consumer crashes after processing messages?
medium
A. Messages are reprocessed on restart, causing duplicates
B. Kafka automatically reassigns partitions to other consumers
C. Messages are lost because Kafka deletes them immediately
D. Consumer cannot rejoin the group due to missing offsets

Solution

  1. Step 1: Understand offset commit role

    Offset commits record progress; disabling commits means no progress saved.

  2. Step 2: Trace failure impact

    On crash, consumer restarts from last committed offset (which is old), reprocessing messages and causing duplicates.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    No offset commit -> consumer may fail to rejoin group due to missing offsets [check]
Hint: No offset commit -> consumer rejoin failure [OK]
Common Mistakes:
4. At 10x scale, which component in the load balancer system is most likely to fail first and why?
hard
A. Load balancer routing tables, because stateful session persistence cannot shard easily
B. Health check workers, due to increased probe volume causing CPU exhaustion
C. Backend servers, because they cannot handle increased traffic without scaling
D. DNS resolvers, due to increased query volume causing cache misses

Solution

  1. Step 1: Identify stateful bottlenecks at scale

    Routing tables maintaining session persistence are stateful and hard to shard, causing scaling limits.

  2. Step 2: Compare other components

    Health checks scale horizontally; backend servers scale independently; DNS resolvers can be cached and distributed.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Stateful routing tables limit scaling due to session affinity [check]
Hint: Stateful routing tables limit scaling first [check]
Common Mistakes:
5. At 10x scale, which component in a Rendezvous Hashing-based distributed system is most likely to fail first and why?
hard
A. The client-side routing logic fails due to maintaining large node lists and computing scores
B. The central coordinator fails due to increased coordination overhead
C. The hash function computation becomes a CPU bottleneck due to increased node and key counts
D. The network bandwidth saturates because all nodes broadcast state to each other

Solution

  1. Step 1: Identify system components at scale

    Rendezvous Hashing is decentralized, so no central coordinator (The central coordinator fails due to increased coordination overhead) exists. Nodes do not broadcast state to all others (The network bandwidth saturates because all nodes broadcast state to each other) in typical implementations.

  2. Step 2: Analyze client-side routing impact

    Clients must compute scores for all nodes to pick highest; at 10x scale, this computation and memory for node lists become bottlenecks.

  3. Step 3: Consider hash computation cost

    Hash computations (The hash function computation becomes a CPU bottleneck due to increased node and key counts) are lightweight compared to maintaining large node lists and score computations.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    Client routing logic scales poorly with node list size -> bottleneck [check]
Hint: Client routing logic chokes on large node lists [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