Refactoring Monolithic Designs for LLD Interviews

Not every LLD prompt starts from a blank canvas. Senior-leaning rounds often hand you a working monolith and ask you to make it maintainable. That is a different sport from Designing Parking Lot from scratch: behavior is sacred; structure is not.

This guide focuses on refactoring for LLD interviews — extracting classes, clarifying seams, and leaving a design that still does the same job.

01The Non-Negotiable Rule: Functional Equivalence

If the system used to support “book seat → pay → email ticket,” your refactored model must still support that path. You may introduce interfaces and collaborators, but you may not quietly drop features to make the diagram pretty.

• List the public use cases before you move boxes.
• Treat that list as a regression suite for your design.
• If you change a behavior, say so — that is a product change, not a refactor.

02Smell → Move Mapping

03A Compact Refactoring Script (Interview Pace)

1. Read aloud the monolith’s responsibilities (2 minutes).
2. Tag smells on the diagram — do not fix yet (2 minutes).
3. Pick the highest-leverage cut — usually the biggest SRP breach (1 minute).
4. Extract and rewire (10–15 minutes).
5. Walk a use case across the new types (3 minutes).
6. Stop when the tagged smells are resolved.

Example cut

LibrarySystem handles catalog search, member registration, loan rules, fine calculation, and email reminders. First extract LoanPolicy and NotificationGateway. Leave catalog and members for a second cut if time remains. Two clean seams beat five half-finished ones.

04What Interviewers Listen For

• You preserve behavior deliberately.
• You explain why a boundary exists (“fines change independently of search”).
• You avoid pattern theater.
• You can describe a migration path (facade over old entry point).

LLDCanvas Refactor starts you on monolithic designs with smell tags and asks you to restructure while staying functionally equivalent — the exact constraint these interviews use.

05Worked Sketch: TicketBookingSystem Monolith

Imagine one class that searches shows, holds seats, charges cards, emails tickets, and applies promo codes. Under a behavior lock, a strong first cut looks like:

TicketBookingFacade          // keeps old entry API stable
  CatalogService              // search shows
  SeatHoldService             // reservations + expiry
  PaymentGateway (port)
  PricingPolicy (port)        // promos / base fare
  TicketNotifier (port)

// External behavior unchanged:
book(showId, seatIds, userId, promo?)

You did not redesign the product. You gave each reason-to-change a home and left a facade so callers do not break mid-interview. That is the refactoring story interviewers want to hear.

• If time remains, extract PromoCode rules from a generic PricingPolicy.
• If time is gone, stop — a clear facade + three ports already beats a half-migrated mess.

06Refactor vs Debug-and-Fix vs OCP Drills

Refactor assumes a working mess and equivalence. Debug & Fix centers on resolving specific violations against a target clean design. Change-one-requirement drills stress OCP when a new need arrives mid-design. Use each for the skill it trains; see also open-closed principle under requirement changes.

07Key Takeaways

• Refactoring interviews grade structure under a behavior lock.
• Tag smells first; extract the highest-leverage seam second.
• Walk use cases after every major cut.
• Stop at clarity — not perfection.

Practice on authored monoliths in Refactor and keep a side journal of which smells you still miss under time.