Free lesson · Low Level Design Interviews

Step 6: Extensibility and Trade-offs

Hard15 min readlldinterview-prepoop

Step 6 - Extensibility & Trade-offs

by Olena Marchenko - Software Engineer II, Microsoft Azure Developer Tools.

The first five steps produced the parking lot system. Scope committed, eight entities modeled, ParkingLot as orchestrator with lot-level ReentrantLock, two Strategy interfaces injected, sealed ExitResult, the implementation correct under verification. The design works at the committed scope: three vehicle types, four spot types, three levels, two entry and two exit gates, first-available-compatible allocation, hourly-by-type pricing.

Step 6 is the closing. 4-5 minutes from minute 41 to minute 45. This is where the interviewer probes how the design extends - EV charging, reservations, dynamic pricing, multi-lot chains - and what trade-offs the current design has accepted that would shift under different requirements.

Parking lot is unusually rich for this step. The committed scope is deliberately narrow; the extensions are deliberately broad. A strong candidate uses the closing minutes to demonstrate that the modeling decisions made earlier positioned the design for changes the scope explicitly deferred. The Strategy seams pay off. The composition-vs-inheritance reasoning pays off. The encapsulation discipline pays off. Each modeling decision from Step 2, when articulated in Step 6 as "and here's how it accommodates X," reads as deliberate forward-thinking.

I'll be honest about something: this is the step where I struggled most in my early interviews. I would build a working design and then, when probed about extensions, realize I had no clean story. I'd retrofit hand-wavy answers. The interviewer would conclude my design was incidentally correct rather than deliberately positioned. After enough rejections, I learned to anchor the closing in the specific modeling decisions made earlier - extension projections that reference real seams in the design, not generic hand-waving.

The Interviewer's Perspective

In the closing minutes, my evaluation focuses on extension projection and trade-off articulation.

Did they project extensions through the design's actual seams? EV charging through composition with a Chargeable capability interface (because the modeling phase noted this as the alternative to inheritance). Reservations through a layer over the existing allocation strategy (because allocation is already pluggable). Dynamic pricing as another PricingStrategy implementation (because the Strategy interface already exists). Multi-lot chains as a federation layer above the ParkingLot. Strong candidates anchor each extension in a specific Step 2 or Step 3 decision; weak ones produce generic extensions disconnected from the design.

Did they surface trade-offs unprompted? Lot-level lock contention at scale. Count-based capacity not bounding visual occupancy. Three closed vehicle types limiting cross-cutting capabilities. In-process state (no restart survival). Single facility (no orchestration). PaymentProcessor abstraction obscuring real payment failure modes. Strong candidates volunteer these.

Did they handle the OCP probe cleanly? "If we want to add a new allocation strategy, what changes?" The Strategy interface design already answers: zero modification to ParkingLot. New strategy is a new class. Strong candidates surface this connection.

Did they articulate the EV-charging case specifically? This is the canonical probe on parking lot. Strong candidates know exactly how their design accommodates it: a Chargeable capability interface composed onto specific vehicles, a new SpotType for EV-charging spots, the canFit logic extended for charging compatibility. Weak candidates rebuild the model from scratch under prompting.

Did they avoid overclaiming? Senior candidates know the design has accepted real costs. "This works well at moderate scale; at much higher gate counts we'd shift to per-Level locks." Calibrated honesty signals depth.

Did they close cleanly? Final 30 seconds, usually a "what would you change with another hour?" probe. Strong candidates have a quick prioritized answer; weak ones either say "nothing" or trail off.

Closing generates about 5-8% of the interviewer's signal in absolute terms but disproportionately influences the post-interview write-up - recency bias amplifier.

Important: Parking lot's modeling decisions from Step 2 set up the closing in Step 6. Strong candidates explicitly reference Step 2 reasoning when projecting extensions: "I noted in modeling that EV charging would extract a Chargeable capability interface; here's how that lands." This continuity signals deliberate forward-thinking rather than ad-hoc design.

The Candidate's Perspective

The closing phase for parking lot has specific structure:

Initiate without prompting. At minute 41-42, pivot: "Let me close with extensions and trade-offs."

Cover four extensions anchored in the design. EV charging through composition. Reservations as an overlay. Dynamic pricing as a strategy swap. Multi-lot chains as federation. Each one references a specific seam from earlier steps.

Surface five trade-offs unprompted. With shift triggers for each.

Use the "what stays" framing. Most extensions don't break the dual structure or the lock model; they slot into the existing seams. Articulating what stays invariant is the OCP signal.

Calibrate honestly. Name the limits the design has accepted.

Close with prioritized improvement. One-sentence answer for "what next."

Applied to Parking Lot

The extension projections and trade-off articulation specific to this design.

Extension 1: EV Charging

What changes:

The modeling phase deferred EV charging but noted the seam: composition with a Chargeable capability interface rather than inheritance with an ElectricCar subtype. Cashing in that note:

public interface Chargeable {
    int getBatteryCapacityKwh();
    int getCurrentChargePercent();
}

public final class Car extends Vehicle { ... }
public final class ElectricCar extends Vehicle implements Chargeable {
    // Composes Car-like behavior with charging capability
    private int batteryCapacityKwh;
    private int currentChargePercent;
    // ...
}

public enum SpotType { COMPACT, REGULAR, LARGE, HANDICAP, EV_CHARGING }

public class ParkingSpot {
    public boolean canFit(Vehicle vehicle) {
        // ... existing cases ...
        if (this.spotType == SpotType.EV_CHARGING) {
            return vehicle instanceof Chargeable;
        }
        return ...;
    }
}

What stays invariant: ParkingLot orchestration, lock model, Strategy interfaces, ticket lifecycle. What changes: a new vehicle subtype (or composition variant), a new SpotType enum value, the canFit logic extended.

The articulation: "EV charging cashes in the composition note from Step 2. Vehicles implement a Chargeable capability interface - composition over inheritance because being-electric is a cross-cutting characteristic that could attach to any vehicle type. New SpotType.EV_CHARGING. canFit extended to check vehicle instanceof Chargeable. The Strategy interfaces don't change - though we might want a EvAwarePricingStrategy that adds a charging surcharge."

Extension 2: Reservations

What changes:

Reservations layer over the existing allocation. A pre-booked Reservation entity holds a vehicle, a time window, and possibly a preferred spot type. At enter time, the lookup checks for matching reservations before going to the allocation strategy.

public class Reservation {
    private final String reservationId;
    private final Vehicle vehicle;
    private final Instant startTime;
    private final Duration plannedDuration;
    private final SpotType preferredSpotType;
    private final ParkingSpot heldSpot;  // pre-allocated if soft-hold
    private ReservationStatus status;  // ACTIVE, FULFILLED, EXPIRED, CANCELLED
}

public class ParkingLot {
    public Optional<ParkingTicket> enter(Vehicle vehicle) {
        // Check for active reservation first
        Optional<Reservation> reservation = findReservation(vehicle);
        if (reservation.isPresent()) {
            return enterWithReservation(vehicle, reservation.get());
        }
        // Existing flow
        return enterUnreserved(vehicle);
    }
}

What stays invariant: most of the design. What changes: Reservation entity, lookup in enter, possibly held-spot semantics (does the reservation block a spot from being allocated to walk-ups, or does it just guarantee priority?).

The articulation: "Reservations layer over the existing allocation. New Reservation entity. enter checks for active reservations before the standard allocation. Reservations can be hard-hold (spot is unavailable for walk-ups during the window) or soft-hold (priority but not exclusive). Hard-hold is cleaner from a guarantee standpoint but reduces walk-up availability. Choice depends on the lot's business model."

Extension 3: Dynamic Pricing

What changes:

Brand new PricingStrategy implementations. The existing HourlyByTypePricing is one option; alternatives handle time-of-day, day-of-week, demand-based surge, validation discounts, monthly pass discounts.

public class TimeOfDayPricing implements PricingStrategy {
    private final Map<HourRange, Map<SpotType, Money>> ratesByTimeAndType;
    private final Money dailyCap;
    @Override
    public Money calculateFee(ParkingTicket ticket, Duration stayDuration) {
        // Walk the duration; for each hour bucket, look up the rate
        ...
    }
}

public class DemandBasedSurgePricing implements PricingStrategy {
    private final OccupancyMonitor monitor;
    private final PricingStrategy baseStrategy;
    private final SurgeCurve surgeCurve;  // e.g., 1.5x at 80% occupancy
    @Override
    public Money calculateFee(ParkingTicket ticket, Duration stayDuration) {
        Money base = baseStrategy.calculateFee(ticket, stayDuration);
        double surge = surgeCurve.multiplierAt(monitor.currentOccupancy());
        return base.multiply(surge);
    }
}

The DemandBasedSurgePricing example shows decoration - it wraps a base strategy and applies a surge multiplier.

The articulation: "Dynamic pricing is purely new PricingStrategy implementations. The existing strategy was always pluggable; this is the seam paying off. Time-of-day variation walks the duration in hour buckets. Demand-based surge wraps a base strategy with a multiplier based on current occupancy. The Cache class - sorry, the ParkingLot class - doesn't change at all. New strategy is a new class; OCP-friendly."

(I'll catch myself if I confuse the LRU Cache and parking lot during the case study; that's the kind of slip that happens when you're moving fast.)

Extension 4: Multi-Lot Chains

What changes:

A Federation layer above individual ParkingLots. A ParkingNetwork holds multiple ParkingLots. Cross-lot queries (availability across the network). Cross-lot allocation (direct customers to the nearest lot with availability).

public class ParkingNetwork {
    private final List<ParkingLot> lots;
    private final NetworkAllocationStrategy networkStrategy;
    
    public Optional<NetworkParkingResult> enter(Vehicle vehicle, Location preference) {
        // Find lots with availability near the preference
        // Allocate at the chosen lot
    }
}

What stays invariant: individual ParkingLot design. What changes: a layer above. The lock semantics for individual lots stay; the network layer might add its own coordination.

The articulation: "Multi-lot chains are a layer above. ParkingNetwork holds multiple ParkingLots, each independent. NetworkAllocationStrategy decides which lot to send a vehicle to - nearest with capacity, cheapest, etc. Individual lot design doesn't change. The challenge moves up a level: how to make the network's view of availability consistent? Per-lot capacity counts feed into a NetworkOccupancyView. Strong consistency requires coordination; eventual consistency is often acceptable for advisory information. The architecture is similar to distributed cache - local mechanics stay; the system layer wraps."

Extension 5: IoT Sensor Integration

What changes:

Spots gain sensor-based status updates rather than trust-the-driver tracking. The status changes come from external events (sensor.spotOccupied(spotId)) rather than from explicit enter/exit calls.

public class SensorEventHandler {
    private final ParkingLot lot;
    
    public void onSensorEvent(SpotSensorEvent event) {
        if (event.isOccupied() != lot.getSpot(event.spotId()).isOccupied()) {
            // Reconcile state
            ...
        }
    }
}

The reconciliation between sensor state and ticket state is the interesting part. What if a sensor says a spot is occupied but no ticket was issued? Probably a vehicle that bypassed the gate - security event. What if a sensor says a spot is free but a ticket says it's occupied? Possibly a vehicle that left without paying - ticket goes LOST.

The articulation: "IoT sensors layer reconciliation onto the existing model. Spot status comes from sensor events rather than (or in addition to) explicit enter/exit. The reconciliation logic compares sensor state to ticket state - mismatches signal security events or lost-ticket flows. The base model handles both: sensor says occupied + no ticket = security event; sensor says free + ticket active = vehicle left, transition ticket to LOST."

Extension 6: Lost Ticket Handling

What changes:

The gap surfaced in Step 5. New exit path:

public ExitResult exitWithoutTicket(Vehicle vehicle, PaymentMethod paymentMethod) {
    lock.lock();
    try {
        Optional<ParkingTicket> ticket = findActiveTicketByVehicle(vehicle);
        if (ticket.isEmpty()) {
            return new ExitResult.Failure("No active parking found for vehicle");
        }
        
        ParkingTicket activeTicket = ticket.get();
        activeTicket.transitionTo(TicketStatus.LOST);
        
        // Flat penalty fee
        Money penalty = pricingStrategy.lostTicketPenalty();
        PaymentResult result = paymentProcessor.process(activeTicket, penalty, paymentMethod);
        
        if (result instanceof PaymentResult.Failure failure) {
            return new ExitResult.Failure("Lost-ticket payment failed: " + failure.reason());
        }
        
        // Release and close
        activeTicket.getSpot().release();
        Level level = findLevelOf(activeTicket.getSpot());
        level.increment(activeTicket.getSpot().getSpotType());
        activeTicket.transitionTo(TicketStatus.CLOSED);
        activeTickets.remove(activeTicket.getTicketId());
        
        return new ExitResult.Success(activeTicket, penalty);
    } finally {
        lock.unlock();
    }
}

The articulation: "Lost ticket - the gap from Step 5. New exit method that looks up by vehicle. Transitions ACTIVE → LOST. Charges flat penalty (which means PricingStrategy needs a lostTicketPenalty method, or we extract a LostTicketPricingStrategy). Otherwise the flow mirrors normal exit. Lifecycle already accommodated LOST as a state."

The Extension Impact Map

flowchart LR
    subgraph Small[Small Extensions]
        S1[New PricingStrategy]
        S2[New SpotAllocationStrategy]
        S3[Lost Ticket Path]
    end
    
    subgraph Medium[Medium Extensions]
        M1[EV Charging]
        M2[Reservations]
        M3[IoT Sensors]
    end
    
    subgraph Large[Large Extensions]
        L1[Multi-Lot Federation]
        L2[Persistence Layer]
        L3[Valet Parking Variant]
    end
    
    Small --> R1[Zero changes to ParkingLot<br/>One new class per extension]
    Medium --> R2[Localized changes<br/>New entity + integration point]
    Large --> R3[New architectural layer<br/>Above or alongside ParkingLot]
    
    style Small fill:#34d399,stroke:#10b981,color:#000
    style Medium fill:#fbbf24,stroke:#f59e0b,color:#000
    style Large fill:#a78bfa,stroke:#8b5cf6,color:#fff

The matrix is the OCP visualization. Small extensions land cleanly in the existing seams (Strategies). Medium extensions add new entities but integrate at known points (canFit logic, enter flow). Large extensions are new architectural layers.

The Trade-offs the Current Design Has Accepted

Five worth surfacing unprompted.

Trade-off 1: Lot-level lock contention.

The current ReentrantLock at ParkingLot serializes all gate operations. With 4 gates (2 in, 2 out), the contention is manageable. At 20 gates (large airport), the lock becomes a throughput bottleneck.

Shift trigger: gate counts above ~10. Shift target: per-Level locks with careful lock ordering. Per-Spot locks not advisable due to deadlock risk in cross-spot operations.

Trade-off 2: Count-based capacity doesn't bound visual occupancy.

Our counters track number of spots, not visual occupancy or vehicle size. If oversized vehicles overflow their spots into neighboring spots (common in real lots), the counter says capacity but the lot is visually full. Real systems handle this with size-aware spot allocation and visual sensors.

Shift trigger: lots with frequent oversized vehicles or strict visual capacity rules. Shift target: weight/size-aware allocation with sensor reconciliation.

Trade-off 3: Three closed vehicle types limits cross-cutting capabilities.

Vehicle is a closed set of three subtypes. Adding cross-cutting characteristics (electric, oversize, premium) requires the composition shift articulated in Step 2.

Shift trigger: requirements introduce cross-cutting vehicle characteristics. Shift target: vehicles compose capability interfaces (Chargeable, Oversized, Premium) instead of using deep inheritance.

Trade-off 4: In-process state (no restart survival).

activeTickets is in-memory. JVM crash loses all active parking state. Real systems need persistence.

Shift trigger: production deployment with availability requirements. Shift target: a persistence layer (database or write-ahead log) that activeTickets and spot state replicate to.

Trade-off 5: PaymentProcessor abstraction obscures payment edge cases.

Our design treats PaymentProcessor as a black-box interface. Real payment processing has many failure modes - declines, timeouts, partial captures, refunds, chargebacks. Our design handles only success/failure binary.

Shift trigger: production payment integration. Shift target: richer PaymentResult variants, retry logic, idempotency keys, refund flow.

Trade-off 6: Single facility (no multi-lot orchestration).

The ParkingLot models a single facility. Multi-lot chains require the Federation layer above.

Shift trigger: chain operations across multiple lots. Shift target: ParkingNetwork as articulated in Extension 4.

The Trade-off Matrix

flowchart LR
    subgraph Decisions[Current Decisions]
        D1[Lot-level lock]
        D2[Count-based capacity]
        D3[Inheritance for 3 vehicle types]
        D4[In-process state]
        D5[PaymentProcessor as black box]
        D6[Single facility]
    end
    
    subgraph Costs[Accepted Costs]
        C1[Throughput cap at ~10 gates]
        C2[Visual occupancy not tracked]
        C3[Cross-cutting capabilities awkward]
        C4[No restart survival]
        C5[Payment edge cases not modeled]
        C6[No chain orchestration]
    end
    
    subgraph Shifts[Shift Triggers]
        S1[10+ gates → per-Level locks]
        S2[Oversized vehicles → size-aware]
        S3[EV/Oversize/Premium → composition]
        S4[Production availability → persistence]
        S5[Production payment → richer integration]
        S6[Chain → ParkingNetwork federation]
    end
    
    D1 --> C1 --> S1
    D2 --> C2 --> S2
    D3 --> C3 --> S3
    D4 --> C4 --> S4
    D5 --> C5 --> S5
    D6 --> C6 --> S6
    
    style Decisions fill:#60a5fa,stroke:#3b82f6,color:#fff
    style Costs fill:#fbbf24,stroke:#f59e0b,color:#000
    style Shifts fill:#34d399,stroke:#10b981,color:#000

The matrix demonstrates calibrated design awareness. Each decision is deliberate; each cost is named; each shift is articulated.

The Conversation

What closing actually sounds like.

Strong Candidate

Interviewer: [checks time] "About 4-5 minutes left."

Candidate: "Let me close with extensions and trade-offs.

Four extensions, each anchored in a Step 2 or Step 3 decision.

EV charging cashes in the composition note from Step 2. Vehicles implement a Chargeable capability interface - composition over inheritance because being-electric is cross-cutting. New SpotType.EV_CHARGING. canFit extended to check vehicle instanceof Chargeable. The Strategy interfaces don't change.

Reservations layer over the existing allocation. New Reservation entity. enter checks for active reservations before standard allocation. Hard-hold vs soft-hold is a business decision; the model supports either.

Dynamic pricing is purely new PricingStrategy implementations. TimeOfDayPricing walks duration in hour buckets. DemandBasedSurgePricing wraps a base strategy with a multiplier. The ParkingLot class doesn't change - OCP-friendly because the seam was extracted in Step 3.

Multi-lot chains are a layer above. ParkingNetwork holds multiple ParkingLots. Individual lot design unchanged. Network-level concerns become coordination and availability views."

Candidate: "Trade-offs the design has accepted, unprompted.

Lot-level lock works at moderate gate counts. At 10+ gates, contention becomes the bottleneck - shift to per-Level locks with careful ordering.

Count-based capacity doesn't track visual occupancy. Oversized vehicles overflowing spots aren't reflected in counter values. Size-aware allocation with sensor reconciliation is the production solution.

Three closed vehicle types limit cross-cutting capabilities. Adding electric or premium requires the composition shift I articulated for EV.

In-process state - activeTickets lives in memory. JVM crash loses it. Persistence layer would address this.

PaymentProcessor abstraction obscures real payment failure modes. Our design handles binary success/failure. Production payment has declines, timeouts, partial captures, refunds - richer integration needed.

Single facility - no multi-lot orchestration. The Federation extension addresses this when needed."

Interviewer: "What would you change with another hour?"

Candidate: "Three things in priority. First, implement the lost-ticket exit path I sketched in Step 5 - production-relevant gap. Second, add a persistence facility for activeTickets and spot state - survives JVM restarts. Third, implement EV charging as a Chargeable capability composition - demonstrates the seam and unblocks the most common extension. Beyond that we're into multi-lot federation, which is a separate system."

About 4 minutes. Four extensions anchored in design decisions. Six trade-offs unprompted with shift triggers. Final priorities concrete. Closing reads as deliberate.

Weak Candidate

Interviewer: [checks time] "About 4-5 minutes left."

Candidate: "Um. For extensions, I could add electric vehicles. I'd add an ElectricCar subclass."

Interviewer: "What if a vehicle is both electric and oversize?"

Candidate: "Then I'd need... hmm. Multiple inheritance? Or a flag on the vehicle?"

Interviewer: "What about reservations?"

Candidate: "I'd add a Reservation class that pre-allocates spots."

Interviewer: "How does that interact with walk-up allocation?"

Candidate: "I'd check for reservations before allocating to walk-ups."

Interviewer: "Dynamic pricing?"

Candidate: "I'd update PricingStrategy."

Interviewer: "Right - the Strategy interface is already there. What about trade-offs?"

Candidate: "The current design uses synchronized methods which are slow at scale."

Interviewer: "I think you used ReentrantLock?"

Candidate: "Right. ReentrantLock. Still serializes operations."

Interviewer: "What would you change with another hour?"

Candidate: "Maybe implement more strategies. And add tests."

About 4 minutes. Each extension prompted into rather than self-articulated. Trade-offs surfaced shallow. No connection to specific Step 2/3 decisions. The candidate produced acceptable answers but never demonstrated the deliberate forward-thinking that signals senior.

Strong vs Weak: Closing Patterns

Common Mistakes

The parking lot closing failures:

No closing phase. Implementation runs to minute 44; no extension or trade-off discussion.

Generic extensions. "I'd add a Reservation class." Without articulating where it integrates or what stays invariant.

Disconnected from prior design. Extensions don't reference the specific modeling decisions made earlier - the EvictionPolicy seam, the Chargeable composition note, the Strategy interface signatures.

ElectricCar subclass trap. Adding an ElectricCar inheritance subtype when the modeling phase deliberately deferred this in favor of composition. Misses the modeling continuity.

Confusion on cross-cutting capabilities. Not knowing what to do when a vehicle has multiple cross-cutting characteristics (electric and oversize). The composition design handles this; the inheritance design doesn't.

Overclaiming. "ReentrantLock scales to any throughput." "No real trade-offs."

No unprompted trade-offs. Waiting for the interviewer to ask. Loses the highest-leverage signal.

Lost-ticket as forgotten. Walking through Step 5's gap acknowledgment and not bringing the extension back in Step 6 as the priority fix.

Warning: The most common closing mistake on parking lot is producing extensions disconnected from the modeling decisions in Step 2. Strong candidates explicitly tie each extension to a seam articulated earlier. The continuity signals deliberate forward-thinking; the disconnect signals incidental design.

What "Good" Looks Like

Self-initiated closing pivot. At minute 41.

Four extensions anchored in Step 2/3 decisions. EV → composition. Reservations → enter integration. Dynamic pricing → Strategy implementations. Multi-lot → Federation layer.

EV via Chargeable capability composition. Not ElectricCar subclass.

Six trade-offs surfaced unprompted. With shift triggers.

Honest calibration. Lot-level lock has limits. Count-based capacity has limits. In-process has limits. Named without defensiveness.

OCP reflection. "Strategy seam pays off - new pricing is a new class, not a modification."

Prioritized improvement. Three concrete next steps with reasoning.

Time discipline. Lands at minute 44-45.

A candidate hitting seven or more signals has produced senior closing work.

Try It

Exercise: Drill the closing phase for parking lot:

1. Practice the four-extension articulation. EV, reservations, dynamic pricing, multi-lot. Each in 45-60 seconds, anchored in a specific design decision.

2. Drill the Chargeable composition pattern. "Vehicles implement Chargeable. New SpotType.EV_CHARGING. canFit extended." Until reflexive.

3. Practice the six-trade-off articulation. Lot-level lock, count-based, closed vehicle types, in-process, PaymentProcessor, single facility. Each with its shift trigger. Total under 3 minutes.

4. Drill the "what would you change with another hour" answer. Three ranked specific items. Lost-ticket, persistence, EV. Reflexive within 30 seconds.

5. Audit your closings. Listen for overclaiming, generic extensions, disconnected projections. Each is signal-loss.

This is the last step of the parking lot case study. The six-step methodology has carried us from "design a parking lot" through scope commitment, modeling, class structure, implementation, verification, and now extension projection. The same methodology applies to any LLD problem - the template is the methodology; the discipline is what makes it work. Parking lot's lesson, more than other problems, is that modeling decisions cast forward - choices made at minute 15 set up extensions discussed at minute 44. Designing with that forward-thinking is the senior signal that lands hardest.

Back to Low Level Design Interviews