Reservation and hold system in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Identify the correct component for handling reservation expiration

In a reservation and hold system, which component is best suited to automatically release held items after a timeout period?

A The user interface component that prompts users to release holds manually.

B A background scheduler service that tracks hold expiration and releases items.

C The database triggers that delete hold records after a fixed time.

D The payment gateway that cancels holds if payment is not received.

💡 Hint

Think about which part can run tasks independently and periodically.

A background scheduler service can run timed tasks to check and release expired holds automatically, ensuring system consistency without user intervention.

❓ scaling

intermediate

Scaling holds in a high-traffic reservation system

Which approach best supports scaling the hold feature in a reservation system with millions of concurrent users?

A Store hold states in a distributed in-memory cache with TTL (time-to-live) support.

B Keep all hold data only in a single relational database instance.

C Use local session storage on user devices to track holds.

D Write hold information directly to log files for later processing.

💡 Hint

Consider fast access and automatic expiration for large scale.

Distributed in-memory caches with TTL allow fast reads/writes and automatic expiration of holds, which is essential for scaling to millions of users.

❓ tradeoff

advanced

Tradeoff between consistency and availability in hold release

In a distributed reservation system, what is the main tradeoff when choosing to release holds immediately versus eventually?

A Eventual release guarantees immediate availability but sacrifices data durability.

B Immediate release improves availability but causes stale data inconsistencies.

C Immediate release favors consistency but may reduce availability during network issues.

D Eventual release ensures strong consistency but delays user feedback.

💡 Hint

Think about how quickly the system updates state and handles failures.

Releasing holds immediately requires strong coordination, which can reduce availability if parts of the system are unreachable, but it keeps data consistent.

🧠 Conceptual

advanced

Understanding idempotency in hold requests

Why is idempotency important when processing hold requests in a reservation system?

A It guarantees that holds never expire automatically.

B It ensures holds are always released after a fixed timeout.

C It allows multiple users to hold the same item simultaneously.

D It prevents duplicate holds when the same request is retried due to network errors.

💡 Hint

Consider what happens if a request is sent multiple times.

Idempotency ensures that retrying the same hold request does not create multiple holds or inconsistent states, which is critical in unreliable networks.

❓ estimation

expert

Estimating capacity for hold expiration processing

A reservation system expects 10 million holds daily, each expiring after 15 minutes if not confirmed. How many hold expirations must the system process per second on average?

A Approximately 11,574 expirations per second.

B Approximately 1,157 expirations per second.

C Approximately 6,944 expirations per second.

D Approximately 694 expirations per second.

💡 Hint

Calculate total seconds in 15 minutes and divide total holds by that.

15 minutes = 900 seconds. 10,000,000 holds / 900 seconds = 11,111 holds per second. The closest option is 11,574 expirations per second.

Practice

1. What is the primary purpose of a hold in a reservation and hold system?

easy

A. To delete all reservations from the system

B. To permanently reserve a resource without expiration

C. To cancel a confirmed reservation immediately

D. To temporarily block a resource before final booking

Solution

1. Step 1: Understand the role of a hold

   A hold temporarily blocks a resource to prevent others from booking it while the user decides.

2. Step 2: Differentiate hold from reservation

   A reservation is permanent until canceled, while a hold expires if not confirmed.

3. Final Answer:

   To temporarily block a resource before final booking -> Option D

4. Quick Check:

   Hold = Temporary block [OK]

Hint: Holds are temporary blocks, not permanent reservations [OK]

Common Mistakes:

• Confusing hold with permanent reservation
• Thinking holds never expire
• Assuming holds cancel reservations

2. Which data structure is best suited to track holds with expiration times efficiently?

easy

A. Simple array without ordering

B. Linked list without timestamps

C. Hash map with timestamps and a priority queue for expirations

D. Stack data structure

Solution

1. Step 1: Identify requirements for hold tracking

   We need fast lookup by hold ID and efficient expiration handling.

2. Step 2: Choose data structures

   A hash map allows quick hold lookup; a priority queue orders holds by expiration for timely removal.

3. Final Answer:

   Hash map with timestamps and a priority queue for expirations -> Option C

4. Quick Check:

   Hash map + priority queue = efficient hold tracking [OK]

Hint: Use hash map for lookup and priority queue for expirations [OK]

Common Mistakes:

• Using unordered arrays causing slow expiration checks
• Choosing stack which is LIFO, not suitable for expirations
• Ignoring timestamps in data structure

3. Consider this pseudo-code for confirming a hold:

if hold.exists(hold_id) and not hold.is_expired(hold_id):
    reservation.create(hold.resource)
    hold.remove(hold_id)
    return "Confirmed"
else:
    return "Failed"

What will be the output if the hold has expired?

medium

A. "Failed"

B. "Confirmed"

C. Error due to missing hold

D. "Confirmed" but resource is double booked

Solution

1. Step 1: Check hold existence and expiration

   The code confirms only if hold exists and is not expired.

2. Step 2: Analyze expired hold case

   If hold is expired, condition fails and returns "Failed" without creating reservation.

3. Final Answer:

   "Failed" -> Option A

4. Quick Check:

   Expired hold = "Failed" confirmation [OK]

Hint: Expired holds cause confirmation to fail [OK]

Common Mistakes:

• Assuming expired holds confirm successfully
• Expecting errors instead of failure message
• Ignoring hold expiration check

4. A developer wrote this code to release expired holds:

for hold in holds:
    if hold.expiration_time < current_time:
        holds.remove(hold)

What is the main issue with this code?

medium

A. Holds should not be removed, only marked expired

B. Modifying a list while iterating causes skipped elements or errors

C. Expiration time comparison is incorrect

D. Loop should use while instead of for

Solution

1. Step 1: Understand iteration and modification

   Removing items from a list while iterating over it causes skipping or runtime errors.

2. Step 2: Identify correct approach

   Use a separate list to collect expired holds or iterate over a copy to safely remove.

3. Final Answer:

   Modifying a list while iterating causes skipped elements or errors -> Option B

4. Quick Check:

   Remove during iteration = skipped elements [OK]

Hint: Never remove items from list while looping over it [OK]

Common Mistakes:

• Ignoring iteration modification side effects
• Assuming expiration comparison is wrong
• Thinking loop type causes the issue

5. You need to design a scalable reservation and hold system for a popular event with thousands of simultaneous users. Which approach best ensures no double booking and timely hold expiration?

hard

A. Use distributed locks on resources, store holds with TTL in a distributed cache, and confirm with atomic transactions

B. Store all holds in a single database table without expiration, confirm by updating status

C. Allow multiple holds per resource and resolve conflicts manually later

D. Use client-side timers to expire holds and update server asynchronously

Solution

1. Step 1: Prevent double booking with distributed locks

   Distributed locks ensure only one user can hold a resource at a time across servers.

2. Step 2: Use TTL in distributed cache for hold expiration

   TTL automatically expires holds after timeout, preventing indefinite blocking.

3. Step 3: Confirm holds atomically

   Atomic transactions guarantee reservation creation without race conditions.

4. Final Answer:

   Use distributed locks on resources, store holds with TTL in a distributed cache, and confirm with atomic transactions -> Option A

5. Quick Check:

   Distributed locks + TTL + atomic confirm = scalable, safe system [OK]

Hint: Combine distributed locks, TTL cache, and atomic confirm for scale [OK]

Common Mistakes:

• Ignoring concurrency causing double booking
• Relying on client-side expiration only
• Not using atomic operations for confirmation