Why this matters: a design you can only defend as-built is a design you memorized. Interviewers test understanding by moving the problem around — a new constraint here, a growth assumption there — and grading whether your structure bends or breaks. This lesson walks the variations worth having thought about before the round, and shows how each one lands against the seams from lesson 02.

A second gate: revisiting the single-gate assumption

Our requirement set said one entry gate, and we designed accordingly: arrivals are serialized by the physical world, so park() never races itself. It's worth knowing exactly what that assumption bought — because the moment there are two entry gates, two arrivals can reach assignment at the same time, and the interesting question is where the race actually lives.

Walk the park() flow and it's precise: two concurrent calls can both ask the strategy for a spot, both receive the same nearest spot, and both try to claim it. The bookkeeping mutation — remove from free list, attach ticket — is the critical section. The model itself doesn't change; what's needed is a serialization point around claim, and the design gives you options at different costs:

lock the whole lot        simplest; every park/unpark serializes;
                          fine at parking-lot arrival rates
lock per size-class       arrivals for different sizes don't contend;
                          slightly more care at the "step up a size" path
claim-then-confirm        strategy proposes, claim atomically verifies
                          the spot is still free, retry on loss

The honest engineering answer for a physical parking lot is the boring one — a single lock is plenty for tens of arrivals a minute — and saying that, with the fancier options named but declined, reads as judgment rather than ignorance. What you don't want is availability logic duplicated per gate, where two gates can hold two different opinions about the same spot.

Pricing variations: exercising the seam

Lesson 02 put pricing in a table specifically because pricing is where operators tinker. Test that claim against real schemes:

• Flat per entry — the table's rate becomes per-visit instead of per-hour; price() ignores duration. One method changes.
• Hourly with tiers — first hour premium, cheaper thereafter: the table's value becomes a rate schedule; the rounding rule already lives in price(), so tier math joins it there.
• Daily cap — "never more than ₹X/day": a min() at the end of price().
• Different rates by day or hour — the table gains a time dimension; callers don't change at all, because they never knew what was inside price().

Every variation lands inside PricingTable. Nothing touches Spot, Ticket, or the flows. That's the payoff of the separation, and it's worth stating in exactly those terms when an interviewer floats a pricing change: "that's a data change in the pricing table — no model surgery."

Assignment policies: when "nearest" is wrong

Nearest-to-gate optimizes the driver's walk. Operators sometimes want other things:

• Load balancing across floors — spread wear, avoid congestion on the ramp to floor 1. The strategy's ordering flips from distance to floor-occupancy; the free-list structure might gain a per-floor view.
• Turnover zoning — keep ground-floor spots for short stays. The strategy starts caring about expected duration, which it doesn't have — an honest candidate says so, and notes the input the policy would newly require.
• Fill-from-the-top — some garages drain downward at exit rush. Same interface, inverted comparator.

The point of rehearsing these isn't that any is likely to be asked verbatim; it's noticing the shape of the change. Each variation is a new SpotAssignmentStrategy implementation — until one needs data the interface doesn't carry (like expected duration), at which point the interface itself evolves, and you should be able to say which variations cross that line.

10x the lot

Scale the lot from 400 spots to 4,000 across a campus of structures, and what actually strains?

The data structures don't — per-size trees at 4,000 entries are nothing. What changes is ownership semantics: "nearest to the entry gate" stops being well-defined when there are six entry gates on four structures; availability becomes something drivers want to see before driving in, which pulls a read-only availability view out of the core; and gate hardware becomes multiple concurrent writers, which promotes the second-gate discussion from a variation to the default. The model — fit rule, strategy seam, ticket, pricing table — survives intact. Which is the deeper lesson of this problem: good structure doesn't scale by getting bigger, it scales by not needing to change.