Katkat
Back

Design restaurant shift scheduling

GustoSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

This problem tests your ability to design a scalable scheduling system, specifically focusing on data modeling for temporal availability, handling conflicting shift assignments, and API design for concurrent updates.

Problem Statement

Design a backend system for a restaurant workforce management platform. The system allows restaurant managers to create shifts and employees to claim or be assigned to them.

Functional Requirements

  1. Managers can create, update, and delete shifts for a specific restaurant location.
  2. Employees can view available shifts and request to claim them.
  3. The system must prevent double-booking (an employee cannot be assigned to two overlapping shifts).
  4. Managers can finalize a schedule, locking shifts so they can no longer be modified by employees.

Non-Functional Requirements

  1. High consistency for shift claiming (no two employees should successfully claim the same slot).
  2. Read-heavy workload: Employees check the schedule frequently throughout the day.
  3. Scale: Support 10,000 restaurants with up to 200 employees each.

Deliverables

  1. Data Model: Define the core entities (e.g., Restaurant, Employee, Shift, Assignment) and their relationships.
  2. API Design: Propose endpoints for creating a shift, listing available shifts, and claiming a shift.
  3. Concurrency Strategy: Explain how you will handle the race condition where multiple employees attempt to claim the same shift at the exact same time.
  4. Scalability: Describe how you would cache the shift schedule to optimize read performance.

Hints

Hint 1

Consider using database-level constraints or optimistic locking (e.g., version columns) to ensure that a shift can only be claimed by one person.

Hint 2

Think about whether to store shifts in a relational database for ACID compliance or if a NoSQL solution is better for the read-heavy nature of the schedule view.

Hint 3

For the read-heavy requirement, consider a caching layer like Redis to store the schedule for a specific restaurant and period, updating it only when a change is persisted in the primary database.

Follow-up questions

  • How would you handle a scenario where an employee calls out sick and the manager needs to re-open a shift that was already claimed?
  • How would your architecture change if you needed to support 'preferred' shift notifications for specific employees based on their historical availability?
  • What steps would you take to ensure the system remains performant during peak holiday seasons when thousands of managers create schedules simultaneously?