Why booking tests availability and concurrency in LLD - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why is concurrency control important in booking systems?

Imagine a popular online booking system where many users try to book the same slot simultaneously. Why is concurrency control crucial in this scenario?

A To prevent race conditions that could lead to double booking of the same slot.

B To allow users to book slots even if they are already taken, increasing sales.

C To slow down the booking process so users wait longer and reduce server load.

D To ensure that multiple users can book the same slot at the same time without any restrictions.

💡 Hint

Think about what happens if two people book the same slot at the exact same time.

Concurrency control prevents race conditions where two or more users might book the same slot simultaneously, causing double booking and inconsistent data.

❓ Architecture

intermediate

Which component is essential to handle availability in a booking system?

In a booking system, which component is primarily responsible for managing the availability of slots and preventing conflicts?

A Database with locking or transactional support to manage slot availability.

B User Interface that shows available slots.

C Notification service to alert users about bookings.

D Logging service to record booking attempts.

💡 Hint

Think about where the actual data about slot availability is stored and controlled.

The database manages slot availability using locks or transactions to ensure that no two bookings can reserve the same slot simultaneously.

❓ scaling

advanced

How to scale a booking system to handle high concurrency without losing availability accuracy?

You need to design a booking system that can handle thousands of concurrent booking requests per second without double booking. Which approach best supports this requirement?

A Allow eventual consistency and resolve conflicts manually after bookings are made.

B Use a single database instance with no caching and rely on simple queries.

C Implement distributed locking or use a centralized coordination service like ZooKeeper to manage slot locks.

D Disable concurrency controls to improve speed and fix errors later.

💡 Hint

Think about how to coordinate access to shared resources across many servers.

Distributed locking or centralized coordination ensures that concurrent requests are serialized properly, preventing double bookings even at scale.

❓ tradeoff

advanced

What is the tradeoff when using pessimistic locking for booking availability?

Pessimistic locking locks a slot during booking to prevent others from booking it simultaneously. What is a key tradeoff of this approach?

A It improves system throughput by allowing many users to book simultaneously.

B It allows users to book slots even if they are already locked.

C It eliminates the need for any database transactions.

D It can cause delays or reduced system responsiveness due to waiting for locks to release.

💡 Hint

Consider what happens when many users try to book the same slot and have to wait.

Pessimistic locking prevents conflicts but can reduce responsiveness because users must wait for locks to be released before proceeding.

❓ estimation

expert

Estimate the maximum concurrent booking requests a system can handle with optimistic concurrency control

A booking system uses optimistic concurrency control with version checks on each slot record. If the system can process 500 booking requests per second and the average retry rate due to conflicts is 20%, what is the maximum number of concurrent booking requests the system can handle without significant delays?

A Exactly 500 concurrent requests, since retries do not affect throughput.

B Approximately 400 concurrent requests, accounting for retries.

C More than 600 concurrent requests, because retries improve throughput.

D Less than 300 concurrent requests, due to high retry overhead.

💡 Hint

Calculate effective throughput after accounting for retries.

With 20% retries, effective throughput is 500 / 1.2 ≈ 416 requests per second, so max concurrency is about 400 requests.