Katkat
Back

Design Interviewer Availability and Atomic Booking APIs

TruefoundrySoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

Design a relational data model and concurrent APIs for managing interviewer availability and atomic candidate interview booking.

Scenario

Design an interview scheduling platform where interviewers publish availability windows, candidates browse aggregated open interview slots over a rolling 14-day window, and a candidate books an interview slot. When a candidate books a slot, the system must assign exactly one qualified, available interviewer and guarantee that no interviewer is double-booked.

Requirements

Functional Requirements

  1. Mark Availability (POST /interviewers/{id}/availability): Interviewers can set recurring or discrete 30-minute/60-minute available time blocks.
  2. List Slots (GET /interviews/available-slots): Candidates can query distinct available interview time slots across all eligible interviewers for any range within the next 14 days (supporting timezone offsets).
  3. Book Slot (POST /interviews/bookings): A candidate requests a specific slot (start time, duration, track/topic). The system assigns an available interviewer, confirms the booking, and marks that interviewer as booked for that window atomically.

Non-Functional Requirements

  • Strict Consistency: Zero double-booking of interviewers under high concurrency.
  • Low Latency: Slot queries must return within 100 ms at p95.
  • Fairness & Matching: Fair distribution of interview load among equally qualified interviewers.

Scale & Numbers

  • 5,000 active interviewers; 50,000 candidates active per week.
  • Daily booking volume: ~10,000 bookings/day with spikes (e.g., campus hiring release events with up to 500 booking attempts/second).

What Your Design Should Cover

  1. Data Model: Relational schema (tables, primary/foreign keys, indexes, and constraints) supporting slot intervals and bookings.
  2. API Contracts: Request/response payloads and status codes for the three core endpoints.
  3. Concurrency & Atomicity: Handling race conditions when multiple candidates attempt to book the same slot simultaneously (e.g., optimistic locking, pessimistic locking SELECT FOR UPDATE, or distributed locks).
  4. Scalability & Query Optimization: Efficient querying for rolling 14-day availability across thousands of interviewers without full table scans.
  5. Failure Modes & Observability: Handling interviewer cancellations, timeouts, metrics, and audit logs.

Hints

Hint 1

Normalize interview slots into discrete intervals (e.g., fixed 30-minute or 60-minute blocks aligned to the clock) to simplify availability querying and indexing.

Hint 2

For atomic booking, use a database transaction with `SELECT ... FOR UPDATE SKIP LOCKED` or an optimistic version check on individual slot records to prevent race conditions without blocking unrelated interviewers.

Hint 3

To optimize slot listing over a 14-day window, precompute or cache aggregated slot counts in Redis, but always rely on the primary relational database as the source of truth during booking.

Follow-up questions

  • How would you handle panel interviews that require simultaneously matching two or three specific types of interviewers (e.g., one Systems engineer and one Hiring Manager)?
  • If an interviewer cancels 2 hours before the interview, how would you design an automated reassignment workflow without cancelling the candidate's booking?
  • How would your locking strategy change if we moved from a single relational database instance to a horizontally sharded database or multi-region deployment?