Erick Santana

Designing a Parking Garage Reservation System

3 min read

Video Context: This mock interview (watch full video) walks through designing a parking garage reservation system. The candidate, Tim, discusses requirements, API design, scalability, data modeling, trade-offs, and interview strategies. Below, each section is mapped to its relevant timestamp for focused review.

1. API Design

Video Timestamp: 0:00–4:49
Objective: Define endpoints to handle reservations, payments, and user interactions.
Key Actions:

  • Public Endpoints:
    • /reserve: Takes garage_id, vehicle_type, start_time, and end_time. Returns a reservation_id and allocated spot.
    • /cancel: Accepts reservation_id to release a spot.
    • /payment: Integrates with third-party services (e.g., Stripe) using reservation_id to process payments.
  • Internal Endpoints:
    • /free_spots: Checks availability by garage_id, vehicle_type, and time window.
    • /allocate_spot: Assigns spots based on vehicle type and availability.
  • User Management:
    • /create_account and /login for optional user profiles with email, password, and SSO support.

2. Scale Considerations

Video Timestamp: 9:48–15:30
Objective: Ensure the system handles traffic and avoids overbooking.
Key Actions:

  • Traffic Analysis: Estimated parking garage size (e.g., 2,000 spots per garage) deemed manageable without distributed systems.
  • Read Replicas: Added for read-heavy operations (e.g., checking availability) to reduce load on the primary database.
  • Load Balancing: Sharding by location (e.g., zip code) to distribute queries geographically.
  • Consistency: Prioritized strong consistency (via database locks) to prevent double bookings.

3. Data Types & Database Schema

Video Timestamp: 10:55–16:15
Objective: Model data to track reservations, garages, spots, and users.
Key Actions:

  • Tables Designed:
    • Reservations: reservation_id, garage_id, spot_id, start_time, end_time, paid (boolean).
    • Garages: garage_id, zip_code, compact_rate, regular_rate, large_rate.
    • Spots: spot_id, garage_id, vehicle_type (enum: compact, regular, large), status (e.g., available, reserved).
    • Users: user_id, email, password_hash, optional first_name/last_name.
    • Vehicles: vehicle_id, user_id, license_plate, vehicle_type.

4. System Design Architecture

Video Timestamp: 19:48–23:30
Objective: Outline the high-level infrastructure.
Key Components:

  • Frontend: Web/mobile app for users to reserve spots and pay.
  • Backend Server: REST API handling business logic (reservations, payments).
  • Database: PostgreSQL with primary instance for writes and read replicas for scalability.
  • Third-Party Services: Payment processors (Stripe) and SSO (Google/Facebook).
  • Load Balancer: Routes traffic to read replicas based on location (zip code sharding).

5. Trade-Offs Discussed

Video Timestamp: 24:23–27:45
Objective: Balance competing priorities in design choices.
Key Trade-Offs:

  • Relational vs. NoSQL: Chose PostgreSQL for ACID compliance over NoSQL flexibility.
  • Enum vs. Varchar: Used enums for vehicle_type for performance but acknowledged inflexibility if types change.
  • Strong vs. Eventual Consistency: Prioritized strong consistency for reservations (avoid overbooking) despite higher latency.
  • User Accounts: Optional profiles reduced friction but limited personalization.

6. Interview Analysis & Tips

Video Timestamp: 28:30–End
Objective: Reflect on effective interview strategies.
Key Takeaways:

  • Clarify Requirements First: Tim asked about vehicle types, pricing, and consistency upfront.
  • Opinions Matter: Justified separating payment logic from reservation endpoints for modularity.
  • Admit Uncertainty: Acknowledged gaps (e.g., MySQL’s decimal type) to show self-awareness.
  • Be Conversational: Explained reasoning behind schema choices (e.g., enums) as if collaborating with a peer.

Actionable Tips:

  1. Start with “Why”: Explain design choices to showcase critical thinking.
  2. Balance Detail & Speed: Avoid over-engineering (e.g., skipped distributed systems for small-scale garages).
  3. Call Out Risks: Highlight potential issues (e.g., enum rigidity) to demonstrate foresight.

Final Thoughts

This breakdown shows how a systems design interview balances technical depth with communication skills. By structuring the problem into APIs, scalability, data modeling, architecture, trade-offs, and interview tactics, candidates can tackle complex questions methodically. Always link decisions to user needs (e.g., avoiding double bookings) and business constraints (e.g., flat-rate pricing).

Graph View

Backlinks