Overview
Step 8: close the interview by showing how the design evolves. Interviewers commonly ask follow-ups: add a new seat type, support multiple cities, add dynamic pricing, persist data, scale to many servers, add waitlists. A strong answer names exactly which classes change and which stay untouched, proving the design follows OCP and has clear seams.
Prepare a short 'extension map': for each likely change, the extension point (interface, strategy, event) and the impact. Also discuss what you would do for production: persistence behind repositories, distributed locks or database constraints for concurrency, observability, and testing strategy.
A well-designed house has plumbing and wiring routed so adding a bathroom or a floor is straightforward. A poorly designed one needs walls torn down for every change.
When to use it
- The final minutes of an LLD interview.
- When the interviewer adds a new requirement.
- Design reviews assessing future-proofing.
Where it shows up in interviews
Recognize it when: 'how would you add X?'
- Add dynamic pricing to movie booking
- Add EV charging to a parking lot
- Add express elevators
Where it is used in real software
IDEs and browsers add features via extension points without core changes.
New behavior ships behind flags and new strategy implementations.
Swapping in-memory storage for a database without touching domain logic.
Key terms
- Extension point
- Interface or event where new behavior plugs in.
- Blast radius of a change
- How many classes a new requirement touches.
- Seam
- Place where behavior can be substituted.
- Evolution path
- From in-memory to persistent to distributed.
How it works, step by step
- 1List likely changes
From the prompt's domain and your out-of-scope list.
- 2Map each to an extension point
New strategy, new subclass, new listener.
- 3Name impacted classes
Ideally one or two new classes.
- 4Discuss production evolution
Persistence, distributed concurrency, observability.
- 5Admit limitations
Explain what would need refactoring and why.
Extension map for the movie ticket system
Follow-up requirements
| New requirement | Extension point | Change |
|---|---|---|
| Recliner seat type | SeatType + PricingStrategy | Add enum value and price rule |
| Dynamic (demand) pricing | PricingStrategy | New DemandPricing class |
| New payment provider | PaymentGateway | New adapter |
| SMS on booking | BookingEvents listener | New listener |
| Multiple servers | SeatLockManager | DB conditional update or Redis lock |
| Persistence | Repositories | SQL implementations; domain unchanged |
NOWNew requirement: Recliner seat type | Extension point: SeatType + PricingStrategy | Change: Add enum value and price rule
Most changes are additions, not modifications, which is the evidence of a good design.
Implementation
// New requirement: demand-based pricing. Added as a new strategy; nothing else changes.class DemandPricing implements PricingStrategy { constructor(private base: PricingStrategy, private occupancy: (showId: string) => number) {} price(seat: Seat, show: Show) { const factor = this.occupancy(show.id) > 0.8 ? 1.25 : this.occupancy(show.id) < 0.3 ? 0.85 : 1; return Math.round(this.base.price(seat, show) * factor); }} // New requirement: persistence. The domain depends on this interface already.interface ShowRepository { get(id: string): Promise<Show>; save(show: Show): Promise<void> }class InMemoryShowRepository implements ShowRepository { /* used in the interview */ }class PostgresShowRepository implements ShowRepository { /* added later, same interface */ } // Composition root is the only place that changesconst service = new BookingService(new PostgresShowRepository(pool), new DemandPricing(standardPricing, occupancyOf), stripeAdapter);Complexity and performance
No edits to core logic.
Leave room for it.
Trade-offs
Build seams where change is likely (pricing, providers); do not generalize everything.
In-memory designs are fine for interviews if you explain the path to persistence and distribution.
Variants and related techniques
Publish domain events so new features subscribe without touching core code.
Rules and prices in config or a rule engine.
Common mistakes
- Saying 'I would just add an if statement'.
Fix: Point to the extension point and the new class.
- Ignoring scale when asked.
Fix: Explain distributed locking, persistence, and caching briefly.
Interview questions
How would you add a new vehicle type to your parking lot?
Add a Vehicle subclass or enum value with its size and a spot-fit rule; update the pricing strategy if pricing differs. Allocation and ticketing code stay unchanged because they depend on abstractions.
How would your in-memory design change for multiple servers?
Move state to a database behind the existing repositories, replace in-memory locks with database conditional updates or distributed locks behind the same interface, add idempotency keys, and keep domain logic unchanged.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Extension map for an elevator system | Medium | Seams. |
| Evolve Splitwise to multi-currency and persistence | Hard | Impact analysis. |