Parking Lot

By the Syncfusion DevTutorials team · Last updated October 20, 2026

Design a parking lot: spot sizes, the smallest spot that fits, tickets and fees, then build it against a hidden test suite.

Car parks are commonly used in shopping centres, airports, and office buildings. When a vehicle enters, the system assigns a suitable parking space and records its entry time. When the vehicle leaves, the system calculates the parking fee and makes the space available again.

Although the process appears simple, designing it requires clear decisions about vehicles, parking spaces, tickets, fees, and responsibilities.

In this case study, you will design a car park management system for QuickBite’s new cloud kitchen. Delivery riders will park motorbikes, while suppliers will park larger vehicles such as trucks.

In simple words: we will turn a real car park into a few small classes, each with one job, and prove it works with hidden tests.

What You Will Learn

In this case study, you will:

1. Turn a vague problem into a clear list of requirements.
2. Find the classes by looking for nouns.
3. Choose the smallest free spot that fits a vehicle.
4. Price a stay with a ticket and a pricing strategy.
5. Build the whole lot in the sandbox and pass the hidden tests.

Step 1: Agree on the Requirements

Before designing classes or writing code, first define exactly what the system must do. Clear requirements help you avoid unnecessary complexity and ensure everyone understands the scope of the solution. In an interview, it is a good practice to state these requirements aloud and confirm them before starting the design.

What It Must Do

• Support three parking spot sizes: small, medium, and large.
• Allow bikes to park in any spot size.
• Allow cars to park only in medium or large spots.
• Allow trucks to park only in large spots.
• Always assign the smallest available spot that can accommodate the vehicle.
• Generate a parking ticket containing the allocated spot and the vehicle's entry time.
• When the vehicle leaves, release the occupied spot and calculate the parking fee.
• Charge 20 per hour, round partial hours up to the next hour, and charge for at least one hour.
• Reject a vehicle if there is no suitable available spot.
• Prevent the same vehicle registration number from being parked more than once at the same time.

What We Leave Out

To keep the design focused and manageable, the following features are intentionally excluded:

• Payment processing such as cards, UPI, or wallets (these could be added later using a separate payment strategy).
• Multiple entry and exit gates.
• Advance parking space reservations.

Leaving features out deliberately is an important design skill. It helps you build a clear and complete first version of the system while making it easy to discuss future enhancements if needed.

Step 2: Find the Classes

A simple trick: underline the nouns in the requirements. Most of them become classes. The verbs become methods.

Step 3: Build the Key Parts

Which Spot Fits Which Vehicle

A bike fits anywhere, a car needs a medium or large spot, and a truck needs a large one. Put that in a table, not an if-chain.

The table lists the sizes in order, smallest first, so small vehicles do not waste big spots:

Here is the code:

A table says which spots each vehicle fits

type Size = "small" | "medium" | "large";
type Kind = "bike" | "car" | "truck";

// Smallest first, so small vehicles do not waste big spots.
const FITS: Record<Kind, Size[]> = {
  bike: ["small", "medium", "large"],
  car: ["medium", "large"],
  truck: ["large"],
};

console.log("car fits:", FITS.car.join(", "));
console.log("truck fits:", FITS.truck.join(", "));

Expected output:

car fits: medium, large
truck fits: large

With a table, a new vehicle kind (say, an electric scooter) is one new line.

The Spot

A Spot has an id, a size and a plate. The plate is empty when the spot is free. Here M1 holds car KA01AB1234:

Here is the same idea in code:

Spots know their size and who is in them

type Size = "small" | "medium" | "large";

class Spot {
  plate: string | null = null;
  constructor(readonly id: string, readonly size: Size) {}
  get free(): boolean { return this.plate === null; }
}

const spots = [new Spot("S1", "small"), new Spot("M1", "medium"), new Spot("M2", "medium")];
spots[1].plate = "KA01AB1234";

const freeMedium = spots.filter((s) => s.size === "medium" && s.free).map((s) => s.id);
console.log(freeMedium);

Expected output:

[
  "M2"
]

Finding a Spot

Walk the sizes in the vehicle's order, smallest first, and take the first free spot.

Step through three searches. The lot has S1 (small, taken by B1), M1 (medium, free) and L1 (large, free):

Here is the same idea in code:

Find the smallest free spot that fits

type Size = "small" | "medium" | "large";
type Kind = "bike" | "car" | "truck";
const FITS: Record<Kind, Size[]> = { bike: ["small", "medium", "large"], car: ["medium", "large"], truck: ["large"] };
type Spot = { id: string; size: Size; plate: string | null };

function findSpot(spots: Spot[], kind: Kind): Spot | null {
  for (const size of FITS[kind]) {
    const spot = spots.find((s) => s.size === size && s.plate === null);
    if (spot) return spot;
  }
  return null;
}

const spots: Spot[] = [
  { id: "S1", size: "small", plate: "B1" },
  { id: "M1", size: "medium", plate: null },
  { id: "L1", size: "large", plate: null },
];
console.log(findSpot(spots, "bike")?.id);
console.log(findSpot(spots, "truck")?.id);
console.log(findSpot(spots.slice(0, 1), "car"));

Expected output:

M1
L1
null

The bike skipped the taken S1 and moved up to M1. A car with no medium or large spot gets null.

The Ticket and the Fee

The ticket stores the plate, the spot and the entry hour. Step through three exits for a car that came in at hour 9, with a rate of 20 an hour:

Here is the same idea in code:

The ticket remembers when the car came in

class Ticket {
  constructor(readonly plate: string, readonly spotId: string, readonly inHour: number) {}

  fee(outHour: number, ratePerHour: number): number {
    const hours = Math.max(1, Math.ceil(outHour - this.inHour));
    return hours * ratePerHour;
  }
}

const t = new Ticket("KA01AB1234", "M1", 9);
console.log(t.fee(9.25, 20)); // 15 minutes: still one hour
console.log(t.fee(11, 20));   // exactly 2 hours
console.log(t.fee(11.5, 20)); // 2.5 hours: rounds up to 3

Expected output:

20
40
60

Pricing as a Strategy

Malls change their prices: first hour free, weekend rates, a monthly pass. Pricing is a perfect strategy.

Step through one 2.5-hour stay priced two ways. Hourly(20) charges 60; FirstHourFree(20) charges 40:

Here is the same idea in code:

Pricing as a strategy, so weekend rates are a new class

interface Pricing {
  fee(hours: number): number;
}
class Hourly implements Pricing {
  constructor(private readonly rate: number) {}
  fee(hours: number): number { return Math.max(1, Math.ceil(hours)) * this.rate; }
}
class FirstHourFree implements Pricing {
  constructor(private readonly rate: number) {}
  fee(hours: number): number { return Math.max(0, Math.ceil(hours) - 1) * this.rate; }
}

for (const p of [new Hourly(20), new FirstHourFree(20)]) console.log(p.fee(2.5));

Expected output:

60
40

Lab: Build It

Build the ParkingLot class. The hidden tests park bikes, cars and trucks, check which spots they get, and check the fees.

Predict the Output

Common Mistakes

Practice

What to Remember

• Start with requirements, and say what you leave out.
• Nouns become classes; verbs become methods.
• A vehicle takes the smallest free spot it fits, using a table.
• The ticket remembers the entry time; the fee rounds up.
• Pricing is a strategy, so new rules are new classes.

Further Reading

These are the sources used to check this case study:

• Refactoring.Guru: Strategy: the pricing strategy.
• TypeScript Handbook: Classes: classes, readonly fields and constructors.
• MDN: Math.ceil: rounding up hours.

Next: Elevator. You will design an elevator that serves floors in a fair, sensible order.