Katkat

Design a fair event registration queue API

BloombergSoftware Engineer · Onsite

Last updated

This question tests the ability to design a thread-safe, high-concurrency registration system that handles FIFO ordering, capacity constraints, and efficient cancellation operations.

Problem Statement

Design an in-memory Event Registration Service for a high-demand ticketing platform. The system must support thousands of concurrent requests while ensuring fair, first-come, first-served (FIFO) access.

Requirements

  1. Register: Add a user to the waitlist for a specific event. The registration should succeed only if the event is not at full capacity. Return a unique registration ID.
  2. Cancel: Remove a user from the waitlist by their registration ID. If the registration is removed, the spot should ideally be freed for the next person in line.
  3. Get Status: Retrieve the current position of a user in the queue.

Constraints

  • The system must be thread-safe.
  • Operations Register, Cancel, and GetStatus should ideally run in better than O(N) time, where N is the number of registrations.
  • Assume a maximum capacity per event (e.g., 10,000 spots).

API Interface

class RegistrationService:
    def __init__(self, event_id: str, capacity: int):
        # Initialize the system for a specific event
        pass

    def register(self, user_id: str) -> str:
        # Returns a unique registration ID if successful, else empty string
        pass

    def cancel(self, reg_id: str) -> bool:
        # Removes the user from the queue, returns True if successful
        pass

    def get_position(self, reg_id: str) -> int:
        # Returns the 1-based index in the queue, or -1 if not found
        pass

Example

  • Event capacity is 2. Users A, B, and C register.
  • A and B get spots 1 and 2. C is placed in the queue.
  • If B cancels, C should move up to spot 2.
  • get_position('C_reg_id') should return 2.

Hints

Hint 1

Consider using a combination of a Doubly Linked List for O(1) removals and a Hash Map for O(1) lookups by registration ID.

Hint 2

Since the system requires thread safety, evaluate the trade-offs between using coarse-grained locks versus fine-grained synchronization or lock-free data structures.

Hint 3

If the event capacity is exceeded, keep a separate 'Waitlist' structure; when a spot opens due to a cancellation, promote the next user from the waitlist.

Follow-up questions

  • How would you persist this data to a database to handle system crashes without losing the queue state?
  • If this system were distributed across multiple servers, how would you ensure global FIFO ordering?
  • How would you prevent 'botting' or multiple registrations from the same IP address during the registration phase?