Parking Lot
Compatible allocation and ticket lifecycle
Allocation combines two orderings: compatibility by vehicle size, then a deterministic tie by spot ID. Treat inventory, active tickets, and active vehicles as one state machine: a successful park adds all associated state, and release removes it exactly once. Validation must precede searching so an invalid unused spot cannot slip through.
type Size int
const (Motorcycle Size = iota; Car; Van)
fmt.Println(Car < Van) // ranks make compatibility explicitA ticket number is a successful-operation sequence, not an attempt counter. Capacity failure must leave the number available. Returning a pointer into internal ticket storage would let callers release or rename a vehicle indirectly; return a copied Ticket instead. The same principle applies to availability views.
Go models this service with a struct and pointer-receiver methods. Constructor functions return a pointer; validation failures return errors rather than panicking. Scalars in snapshot structs are copied by value. Maps, slices, and optional pointers still require detached copies when crossing the service boundary. Go maps do not have key iteration order; use ordered slices for ranked results. There are no threads, persistence, wall-clock reads, or external side effects in this exercise.
Put it into practice
Implement the exercise in a full-screen workspace, then run its tests.