Design a fair event registration queue API
BloombergSoftware Engineer · OnsiteLast 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
- 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.
- 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.
- Get Status: Retrieve the current position of a user in the queue.
Constraints
- The system must be thread-safe.
- Operations
Register,Cancel, andGetStatusshould 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?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.