Bird
Raised Fist0

UUID vs Auto-Increment vs Custom ID - Trade-offs at Scale

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
UUID vs Auto-Increment vs Custom ID - Trade-offs at Scale
Comparing unique ID generation strategies for high-scale distributed systems
mediumUnique ID GenerationFreq: common
Prerequisites:Distributed Systems BasicsDatabase Sharding and PartitioningCAP TheoremConsistency Models
⚙️
Functional Requirements
  • Generate globally unique IDs for entities (users, orders, messages) without collisions
  • Support distributed ID generation across multiple data centers
  • Ensure IDs are generated with low latency (<5ms per request)
  • Allow IDs to be sortable by creation time for efficient range queries
  • Support at least 925K writes/sec at peak load
  • Provide APIs for ID generation and validation
📊
Non-Functional Requirements
  • System must support 2 billion daily active users generating 40 messages per user per day
  • End-to-end ID generation latency P99 < 100ms
  • Availability SLA of 99.99% for ID generation service
  • Storage system must handle 100+ TB data retention for 30 days with replication
  • System must scale horizontally without manual sharding
❓
Clarifying Questions to Ask
  • What entities require unique IDs and do they have different ID formats?
  • Is global uniqueness across all data centers mandatory or per region?
  • Are IDs required to be sequential or sortable by creation time?
  • What is the expected peak write QPS and read QPS for ID generation?
  • Is there a preference for numeric vs alphanumeric IDs?
  • What is the maximum acceptable latency for ID generation?
Out of Scope
✗ Business logic for entity creation beyond ID generation
✗ Data analytics or reporting on generated IDs
✗ Security mechanisms beyond basic ID uniqueness and validation
✗ Migration strategies from legacy ID systems
📌
Assumptions
  • 2 billion daily active users (DAU)
  • Each user generates 40 messages per day
  • Average message size is 100 bytes
  • Retention period for data is 30 days
⚡
QPS Calculation
write qps2B × 40 / 86400 ≈ 925,926 writes/sec
peak write qpsAssuming 3× peak factor: 925,926 × 3 ≈ 2,777,778 writes/sec
read qpsAssuming 5 reads per write: 925,926 × 5 ≈ 4,629,630 reads/sec
💾
Storage Estimate
daily storage2B × 40 × 100 bytes = 8,000 TB/day (raw)
retention storage8,000 TB × 30 days = 240,000 TB
with replication240,000 TB × 3 replicas = 720,000 TB (720 PB)
🖥️
Server Estimate
id generation serviceAssuming each server handles 50K writes/sec, need 2,778,000 / 50,000 ≈ 56 servers
storage nodesAssuming each node stores 50 TB, need 720,000 TB / 50 TB = 14,400 storage nodes
🏗️
Architecture Diagram
Architecture Diagram
          +----------------------+
          |  Client Applications  |
          +----------+-----------+
                     |
                     v
          +----------------------+
          |  ID Generation Layer  |
          |  (Snowflake / UUID / |
          |   Custom ID Service)  |
          +----------+-----------+
                     |
                     v
          +----------------------+
          |  Distributed Database |
          |  (Cassandra / Spanner)|
          +----------+-----------+
                     |
                     v
          +----------------------+
          |  Cache Layer (Redis)  |
          +----------------------+
🧩
Components
ID Generation Layer
Generate unique IDs with low latency and high throughput
Why thisTwitter Snowflake algorithm provides time-sortable 64-bit IDs with decentralized generation and no coordination bottleneck
Why notUUIDv4 causes large index sizes and is not time-sortable, hurting DB performance; Auto-increment requires centralized coordination causing write bottlenecks
Distributed Database
Store entities with generated IDs, support high write and read throughput
Why thisApache Cassandra offers linear scalability, tunable consistency, and time-series data model suitable for high write QPS and large data volumes
Why notPostgreSQL requires complex manual sharding and does not scale linearly at 2.7M writes/sec; MySQL auto-increment is a bottleneck at scale
Cache Layer
Serve hot ID lookups with sub-millisecond latency
Why thisRedis supports TTL and fast key-value lookups, reducing load on DB for frequently accessed IDs
Why notMemcached lacks persistence and TTL features, making cache invalidation harder
Client Applications
Request unique IDs and use them for entity creation
Why thisClients can generate IDs locally if using Snowflake, reducing network calls and latency
Why notCentralized ID generation services increase latency and single points of failure
Monitoring and Alerting
Track ID generation latency, error rates, and system health
Why thisPrometheus + Grafana provide real-time metrics and alerting for SLA adherence
Why notBasic logging lacks real-time alerting and visualization needed at scale
🔄
Data Flow
1
Client Application → ID Generation Layer
Request new unique ID
Client may generate ID locally if Snowflake is used
2
ID Generation Layer → Client Application
Return generated unique ID
ID is time-sortable 64-bit integer
3
Client Application → Distributed Database
Write entity with generated ID
Writes are distributed across Cassandra nodes by partition key
4
Distributed Database → Cache Layer
Update cache with new entity ID
Cache TTL ensures eventual consistency
5
Client Application → Cache Layer
Read entity by ID
Cache hit reduces DB load and latency
6
Cache Layer → Client Application
Return cached entity data
Sub-millisecond response improves user experience

Practice

(1/5)
1. A distributed database requires that every write is confirmed by a majority of replicas before acknowledging success to the client. Which replication strategy best fits this requirement?
easy
A. Asynchronous replication with eventual consistency
B. Single-leader replication without acknowledgments
C. Synchronous replication with quorum writes
D. Master-slave replication with delayed slave updates

Solution

  1. Step 1: Identify replication strategy matching majority confirmation

    Synchronous replication with quorum writes requires majority replicas to acknowledge before success.

  2. Step 2: Eliminate asynchronous and single-leader without ack

    Asynchronous replication and single-leader without acknowledgments do not guarantee majority confirmation before success.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Quorum writes ensure majority ack before success [check]
Hint: Quorum writes wait for majority acks before success [OK]
Common Mistakes:
2. In an Active-Passive failover setup without a quorum-based consensus mechanism, what exactly breaks when the active node crashes and the passive node mistakenly assumes active role while the original active recovers?
medium
A. The system automatically merges data without conflicts
B. Split-brain occurs causing data divergence and inconsistent writes
C. Passive node refuses to accept writes until manual intervention
D. Active node permanently loses all data on crash

Solution

  1. Step 1: Understand lack of quorum impact

    Without quorum, passive node cannot safely confirm active node failure, risking split-brain.

  2. Step 2: Failover behavior without consensus

    To avoid split-brain, passive node blocks writes until manual resolution, causing availability loss.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    No quorum -> passive blocks writes to prevent split-brain [check]
Hint: No quorum -> passive blocks writes, avoids split-brain [check]
Common Mistakes:
3. For a vector database supporting real-time updates and low-latency ANN queries, which architecture best balances update speed and query performance?
medium
A. Use a single monolithic HNSW index rebuilt entirely on every update
B. Maintain an immutable HNSW index for bulk data plus a small dynamic index for recent inserts
C. Use a brute-force linear scan for all queries to avoid index complexity
D. Store vectors in a relational DB and compute ANN on-demand

Solution

  1. Step 1: Evaluate update and query trade-offs

    Rebuilding entire HNSW on every update (Use a single monolithic HNSW index rebuilt entirely on every update) is too slow for real-time.

  2. Step 2: Consider hybrid index approach

    Maintaining an immutable bulk index plus a small dynamic index (Maintain an immutable HNSW index for bulk data plus a small dynamic index for recent inserts) allows fast queries and incremental updates.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Hybrid immutable + dynamic HNSW balances update speed and query latency [check]
Hint: Hybrid immutable plus dynamic index enables real-time updates [check]
Common Mistakes:
4. For a distributed file system requiring strong consistency on metadata updates but high availability, which architecture is most appropriate?
medium
A. Use a consensus-based Metadata Server cluster (e.g., Paxos or Raft) to coordinate updates
B. Use a single Metadata Server with synchronous replication to backups
C. Use multiple independent Metadata Servers sharding namespace without coordination
D. Use eventual consistency with asynchronous metadata replication across servers

Solution

  1. Step 1: Analyze consistency and availability needs

    Strong consistency requires coordination; high availability requires fault tolerance.

  2. Step 2: Evaluate architectures

    Consensus-based clusters provide strong consistency and tolerate failures; single server risks downtime; independent shards lack coordination; eventual consistency violates strong consistency.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Consensus clusters balance strong consistency and availability [check]
Hint: Consensus clusters ensure strong consistency with availability [check]
Common Mistakes:
5. Without the metadata service that tracks access frequency and last access time, what failure occurs in the storage tiering system?
medium
A. Clients cannot read data because metadata is required for decryption keys
B. Data migration workers cannot decide when to move data, causing stale data to remain in expensive hot storage
C. Data blocks are duplicated across all tiers, increasing storage cost
D. Data is immediately archived without validation, causing data loss

Solution

  1. Step 1: Role of metadata service

    Metadata tracks access patterns to trigger tier migration safely without data loss.

  2. Step 2: Consequence of missing metadata

    Without metadata, migration workers may archive data prematurely without validation, causing permanent data loss.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Missing metadata -> unsafe archiving -> data loss [check]
Hint: Metadata missing -> unsafe archiving -> data loss [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