Bird
Raised Fist0

Ticket Server Pattern for Centralized ID Generation

HLDmediumInterview freq: medium
Choose your preparation mode4 modes available
▶
Request Trace
Step 1/5
Load Balancer

Receives client HTTP request for new unique ID

Load Balancer selects a Ticket Server instance

Protocol:HTTP
BeforeClient request arrives at Load Balancer
AfterRequest forwarded to Ticket Server
Ticket Server

Generates a new unique ticket ID

Ticket Server uses internal counter or sequence

Protocol:Internal
BeforeTicket Server ready to generate ticket
AfterUnique ticket ID generated
Cache (Redis)

Caches the generated ticket ID

Ticket Server issues Redis SET command

Protocol:Redis SET
BeforeTicket ID not present in cache
AfterTicket ID cached for fast future access
Cassandra DB

Persists the ticket ID durably

Ticket Server inserts ticket record via CQL

Protocol:CQL INSERT
BeforeTicket ID only cached, not persisted
AfterTicket ID durably stored in Cassandra
Monitoring & Alerting

Records metrics and health status

Monitors ticket generation latency and errors

Protocol:Internal metrics
BeforeNo recent ticket generation metrics
AfterUpdated metrics reflect new ticket generation
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│ Load Balancer │
└───────┬───────┘
        │ HTTP Request
        ▼
┌───────────────┐
│ Ticket Server │
└───────┬───────┘
        │ Generate Ticket
        ▼
┌───────────────┐
│ Cache (Redis) │
└───────┬───────┘
        │ Redis SET
        ▼
┌───────────────┐
│ Cassandra DB  │
└───────┬───────┘
        │ CQL INSERT
        ▼
┌───────────────────────┐
│ Monitoring & Alerting │
└───────────────────────┘

This architecture uses a centralized Ticket Server pattern to generate unique IDs. Incoming client requests hit the Load Balancer, which routes them to a Ticket Server instance. The Ticket Server generates a unique ticket ID using an internal sequence. To optimize performance, the ticket is cached in Redis for fast retrieval. Simultaneously, the ticket is durably persisted in Cassandra DB to ensure fault tolerance and data durability. Monitoring & Alerting continuously track system health and ticket generation metrics to detect anomalies early. This vertical flow ensures scalability and reliability by separating concerns: Load Balancer for distribution, Ticket Server for ID generation, Redis for caching, Cassandra for persistence, and monitoring for operational insight.

Primary Focus

✓

Practice

(1/5)
1. A distributed cache system must evenly distribute keys across nodes and gracefully handle node failures without massive key remapping. Which component or technique best addresses this requirement?
easy
A. Implementing consistent hashing with virtual nodes
B. Storing all keys in a single master node for centralized control
C. Using a simple modulo hash function on node count to assign keys
D. Using random key assignment to nodes without hashing

Solution

  1. Step 1: Understand key distribution needs

    Simple modulo hashing (Using a simple modulo hash function on node count to assign keys) causes massive remapping when nodes change, failing graceful scaling.
  2. Step 2: Evaluate consistent hashing benefits

    Consistent hashing with virtual nodes (Implementing consistent hashing with virtual nodes) minimizes remapping and balances load even with node failures.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Consistent hashing with virtual nodes -> minimal key remapping on node changes [check]
Hint: Consistent hashing + virtual nodes minimize remap on node changes [OK]
Common Mistakes:
2. A system design interview requires you to explain how you handle conflicting requirements between latency and consistency. Which component or approach best helps you present this trade-off clearly to the interviewer?
easy
A. Use a decision matrix comparing latency and consistency impacts per component
B. Avoid discussing trade-offs and emphasize only the chosen technology
C. Describe only the eventual consistency model without latency details
D. Focus solely on the fastest technology without discussing consistency implications

Solution

  1. Step 1: Identify the need to clarify trade-offs

    Presenting trade-offs requires explicit comparison of conflicting requirements, such as latency vs consistency.
  2. Step 2: Use a decision matrix for clarity

    A decision matrix systematically compares options, showing pros and cons clearly, which helps interviewers understand your reasoning.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Decision matrix clarifies trade-offs explicitly [check]
Hint: Use decision matrices to clarify conflicting trade-offs [check]
Common Mistakes:
3. In a primary-replica system, what exactly breaks if the replication log (WAL) on the primary is lost before being sent to replicas?
medium
A. Replicas request full data snapshot from primary, causing high load and delayed recovery
B. Primary blocks all writes until WAL is restored, causing system-wide write unavailability
C. Primary loses committed transactions permanently, causing data loss and inconsistency
D. Replicas continue serving stale reads but cannot apply new writes, causing data divergence

Solution

  1. Step 1: Understand WAL role in replication

    WAL is the source of truth for replicas to catch up incrementally.
  2. Step 2: Trace failure impact

    If WAL is lost, replicas cannot catch up incrementally and must request full snapshot, causing load and delay.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Lost WAL -> replicas request full snapshot -> recovery delay [check]
Hint: Lost WAL -> full snapshot fetch delays recovery [check]
Common Mistakes:
4. If the Kafka cluster used for fan-out events crashes and loses the latest messages, what exactly breaks in the newsfeed delivery?
medium
A. The system falls back to synchronous push, increasing write latency
B. Posts published just before the crash are lost; followers never see them
C. Followers receive duplicate posts due to re-delivery attempts
D. Delivery Workers block indefinitely waiting for missing messages

Solution

  1. Step 1: Understand Kafka's role in fan-out

    Kafka buffers fan-out events; Delivery Workers consume from Kafka to deliver posts asynchronously.
  2. Step 2: Trace failure impact

    If Kafka crashes and loses messages, Delivery Workers waiting on those messages block or stall, causing delivery delays.
  3. Step 3: Eliminate other options

    Duplicates (A) occur with retries, not loss. Lost posts (B) happen but are not the immediate failure mode. Fallback to synchronous push (D) is not automatic.
  4. Final Answer:

    Option D -> Option D
  5. Quick Check:

    Kafka crash causes Delivery Workers to block waiting for lost messages [check]
Hint: Kafka crash blocks Delivery Workers waiting for messages [check]
Common Mistakes:
5. For ranking answers in the feed, which approach is better given the need for real-time updates and complex ranking signals including user behavior and spam scores?
medium
A. Use batch processing with daily recomputation of rankings in a data warehouse
B. Use client-side ranking to reduce server load and latency
C. Use a simple heuristic ranking computed at write time with no model updates
D. Use an online feature store with real-time scoring and incremental model updates

Solution

  1. Step 1: Evaluate batch vs real-time ranking

    Batch (A) is too stale for real-time user behavior; heuristic (C) lacks adaptability; client-side (D) cannot access server-side signals securely.
  2. Step 2: Online feature store benefits

    Online feature stores enable real-time scoring with fresh data and incremental model updates, supporting complex signals and spam detection.
  3. Final Answer:

    Option D -> Option D
  4. Quick Check:

    Online feature store supports real-time, complex ranking [check]
Hint: Real-time ranking needs online features, not stale batch [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