How do you approach Design Parking System?

Track the remaining count for each of the three car types - a length-3 array or a map keyed by carType works well.

What is the time complexity of Design Parking System?

Time complexity: O(1) per operation.. Space complexity: O(1) - just three counters..

What are common mistakes on Design Parking System?

Hitting the stated complexity for one operation by making another linear. These problems grade every operation. Keeping two structures in sync but updating only one of them on the delete path. Skipping the capacity edges: insert when full, read when empty.

gitGood.dev

← Back to problems

Design Parking System

EasyObject-Oriented Design

Description

Design a parking system for a parking lot that has three kinds of spaces: big, medium, and small, with a fixed number of slots of each kind.

The system is initialized with the number of big, medium, and small slots.
addCar(carType) checks whether there is a free slot for the given car type. carType is 1 (big), 2 (medium), or 3 (small). A car can only park in a slot of its own type. Returns true if a slot was available (and parks the car, decrementing that slot count), or false if no slot of that type is free.

Implement the function parkingSystem(big, medium, small, operations) where the first three arguments are the initial slot counts and operations is a list of [op, ...args]: ["addCar", carType]. Return the list of results, one per operation (use null for operations that return nothing - though every operation here returns a boolean).

Example 1

Input: big = 1, medium = 1, small = 0, operations = [["addCar",1],["addCar",2],["addCar",3],["addCar",1]]

Output: [true, true, false, false]

Example 2

Input: big = 2, medium = 0, small = 0, operations = [["addCar",1],["addCar",1],["addCar",1]]

Output: [true, true, false]

Example 3

Input: big = 0, medium = 0, small = 0, operations = [["addCar",1],["addCar",2],["addCar",3]]

Output: [false, false, false]

Constraints

0 <= big, medium, small <= 1000. carType is 1, 2, or 3. At most 1000 operations.

Design Parking System: approach, complexity and pitfalls

An easy design problem, graded against 6 test cases (3 of them hidden).

The pattern: Design

Build a working data structure to an API - LRU caches, rate limiters, and iterators.

Reach for it when you see: "Design a class supporting these operations in O(1)" - an API rather than a single function.

If you are stuck

Show the 3-step hint ladder

Track the remaining count for each of the three car types - a length-3 array or a map keyed by carType works well.
On addCar(carType), if the remaining count for that type is greater than 0, decrement it and return true; otherwise return false.
Index carefully: carType 1, 2, 3 map to big, medium, small. An off-by-one here is the classic bug.

The optimal approach

Show the approach: The approach

Keep the remaining capacity for each car type in a small lookup keyed by `carType` (1 -> big, 2 -> medium, 3 -> small). Each `addCar` checks whether that type still has a free slot; if so it decrements and returns true, otherwise it returns false. Every operation is constant time.

Time: O(1) per operation.
Space: O(1) - just three counters.

The full reference solution in every supported language stays in the editor above - reveal it there once you have had a real attempt.

What the tests check

Read off this problem's own test suite, so these are the cases a submission actually has to survive.

Zero. Zero appears in the input, which is the value most likely to break a truthiness check used in place of an explicit comparison.

Common Design mistakes

These apply to the pattern as a whole, not just this problem.

Hitting the stated complexity for one operation by making another linear. These problems grade every operation.
Keeping two structures in sync but updating only one of them on the delete path.
Skipping the capacity edges: insert when full, read when empty.