AI Course
    NEW
    Placements

    Progress

    0%

    What is Software Design?High-Level vs Low-Level Design — Drawing the BoundarySoftware Architecture vs Software DesignFunctional vs Non-Functional RequirementsThe Software Design Process and Design ThinkingCharacteristics of Good Software DesignCommon Software Design MistakesHow to Read and Write Design DocumentsThe Framework: How to Approach LLD Problems

    Introduction to OOP and the Java Memory ModelClasses, Objects, and the this KeywordConstructors and Object InitializationEncapsulation and Access ModifiersAbstraction : Interfaces vs Abstract ClassesInheritance and Its TypesPolymorphism : Compile-Time vs RuntimeAssociation, Aggregation, and CompositionDependency RelationshipsGenerics and Type SafetyThe Golden Rule : Composition Over Inheritance

    Introduction to Design PrinciplesSingle Responsibility PrincipleOpen-Closed PrincipleLiskov Substitution PrincipleInterface Segregation PrincipleDependency Inversion PrincipleDRY, KISS, and YAGNI PrinciplesHigh Cohesion and Loose CouplingLaw of DemeterSeparation of Concerns and Information HidingDesigning for Testability : The Ultimate Proof of Loose Coupling

    Why UML Matters in LLDClass DiagramsSequence DiagramsActivity DiagramsState DiagramsComponent and Object DiagramsUsing UML Effectively in InterviewsCommon UML Mistakes to Avoid

    What Are Design Patterns?History and the Gang of FourCategories of Design PatternsHow to Choose a Design PatternAnti-Patterns and Common MisuseDesign Patterns Interview Strategy

    Creational Patterns OverviewSingleton Pattern: Including Thread-Safe and Bill Pugh ImplementationsFactory Method PatternAbstract Factory PatternBuilder and Fluent Builder PatternPrototype PatternFactory vs Builder : When to Use WhichReal-World Usage of Creational Patterns

    Structural Patterns OverviewAdapter PatternBridge PatternComposite PatternDecorator PatternFacade PatternProxy PatternFlyweight PatternAdapter vs Facade vs ProxyReal-World Usage of Structural Design Patterns — How Spring Security Uses Filters and Proxies

    Behavioral Patterns OverviewStrategy PatternObserver PatternCommand PatternChain of ResponsibilityTemplate Method PatternState PatternMediator PatternIterator PatternMemento PatternVisitor PatternStrategy vs State — Key DifferencesReal-World Usage of Behavioral Patterns

    Introduction to Domain ModelingIdentifying Entities and Value ObjectsAggregates and Aggregate RootsDomain ServicesRepositories in Domain DesignBusiness Rules ModelingDomain EventsDesigning Rich vs Anemic Domain ModelsPutting It Together — Full Domain Model Walkthrough

    Introduction to API Design — Principles and GoalsREST Principles and Resource ModelingDTO Design and Mapping Strategies — MapStruct and JacksonRequest and Response DesignInput Validation DesignError Handling and Standardized Error ResponsesPagination, Filtering and SortingAPI Versioning StrategiesIdempotency in APIsAPI Security BasicsDesigning Internal vs External APIs

    Introduction to Persistence DesignThe Repository Pattern — Spring Data JPA Under the HoodDAO vs Repository PatternTransactions and ACID PropertiesUnit of Work PatternOptimistic vs Pessimistic LockingLazy Loading vs Eager Loading and the N+1 ProblemCaching FundamentalsWrite-Through vs Write-Back vs Cache-AsidePersistence Design Best PracticesDesigning for Data Consistency in Concurrent Systems

    Introduction to Concurrency — Threads vs ProcessesThread LifecycleThread Class vs Runnable vs CallableThe Executor Framework and Thread PoolsSynchronization and LocksReentrantLock and ReadWriteLockSemaphores and Countdown LatchesConcurrent Collections — ConcurrentHashMap and FriendsFuture and CompletableFuture for Async DesignThread Communication — Wait, Notify, NotifyAllCommon Concurrency Problems — Deadlock, Starvation, Race ConditionsDesigning Thread-Safe ClassesConcurrency Design Best Practices

    Introduction to Event-Driven ArchitectureThe Publisher-Subscriber ModelObserver Pattern vs Pub-Sub — Where They DifferEvent Modeling — Designing Good EventsMessage Queues — Concepts and Internal DesignEventual Consistency and What It Means for Object DesignEvent Sourcing — Concepts and When to Use ItCQRS — Command Query Responsibility SegregationCommon Pitfalls in Event-Driven Systems

    Logging Fundamentals and Best PracticesAudit LoggingMonitoring and Metrics DesignHealth ChecksRetry Mechanisms and Backoff StrategiesCircuit Breaker PatternRate Limiting AlgorithmsFeature FlagsDesigning for Observability — Putting It All Together

    How to Approach Any LLD Case Study — The 45-Minute FrameworkDesign a Parking LotDesign an Elevator SystemDesign a Vending MachineDesign an ATM MachineDesign a Chess GameDesign Tic-Tac-ToeDesign Snake and LadderDesign a Library Management SystemDesign a Logging FrameworkDesign an Inventory Management SystemDesign a Car Rental SystemDesign a Hotel Booking SystemDesign a URL ShortenerDesign Splitwise

    Advanced LLD — What Changes at the Senior LevelDesign a Movie Ticket Booking System — Handling Concurrency and LockingDesign an E-Commerce Shopping Cart and Order FlowDesign a Notification System — Internal Class OrchestrationDesign a Rate LimiterDesign a Job SchedulerDesign a Real-Time Chat System — WebSocket Handlers and Message Queues at the Class LevelDesign a Pub-Sub System Like Kafka — Internal Data Structures of the BrokerDesign a Payment Processing SystemRequirement Gathering Techniques for InterviewsIdentifying Entities and Relationships Under PressureChoosing Design Patterns in an InterviewDiscussing Trade-Offs ConfidentlyCommon LLD Interview MistakesMock LLD Interview Walkthrough — End to EndWhat to Do After the Interview — Learning from Every Session

    Advanced LLD: What Changes at the Senior Level

    Learning Objectives#

    • Understand that senior LLD is not "more classes" or "harder problems"; it is a different posture toward the same problems.
    • Learn the three upgrades interviewers look for: naming the race before it is pointed out, defending every trade-off with a reason, and holding the interview's direction.
    • See where the class-design floor is and why, above it, the interview stops being about correctness and becomes about judgment.

    Introduction#

    Here is a fact about the senior loop that junior candidates refuse to believe: the case study is usually the same one. Parking lots do not get harder because you interview for a staff role. The elevator, the movie tickets, the rate limiter, they are all the same nouns and the same verbs. What changes is the bar for what counts as a pass, and that bar is not measured in classes or patterns. It is measured in how much of the interview you drive, how early you find the race condition, and whether every decision you made has a reason you can defend when pushed. A mid-level candidate can design a correct parking lot. A senior candidate can design a correct parking lot and tell you why the floor-count lookup is a TreeMap, what breaks if two cars enter at once, and why the pricing seam is placed exactly where it is. The difference is not the drawing. The difference is the reasoning attached to every mark.

    Problem Statement#

    The concrete failure mode is the candidate who treats the senior round as a quantity problem. More classes, more patterns, more diagrams, longer walkthroughs. They add a ParkingLotObserver, a PaymentStrategy with four implementations, a repository layer, and an event bus, and they present it with the confidence of someone who has read the interview books. The interviewer asks one question: "why?" Why four payment strategies when the requirements name one? Why an observer when nothing in the system needs to react? And the candidate has no answer, because the features were added to look senior, and the one thing they cannot fake is a reason.

    That is the failure. At the senior level, adding design is indistinguishable from being lost. The interviewer cannot tell whether you are showing depth or hiding confusion, and the tiebreaker is whether you can say what each piece is for and what you would do without it. Most candidates who fail the senior round fail it not because their design was wrong but because their design was unjustified, and they had nothing to say when the justification was demanded.

    Core Concept#

    The senior upgrade has three parts, and they are not about the code.

    Part one: find the race yourself. In every case study there is a concurrency question the interviewer has waiting. The parking lot has the double-spot-assignment. The movie booking has the double-seat-sale. The inventory has the last-unit decrement. A mid-level candidate answers the race when asked, if they are good. A senior candidate says "the interesting bit here is that two requests could pick the same spot, so the find-and-assign has to be atomic" in the same breath as drawing the spot, before the interviewer can ask. Finding the race unprompted is the single strongest signal in an LLD interview, because it proves you have run the walkthrough under load, not just the happy path. Interviewers remember the candidate who found their intended question.

    Part two: every decision comes with its rejected alternative. This is the upgrade that separates the people who read about design from the people who do it. "Why a TreeMap for spot search?" "Because we always search by size, and the map gives us a ceiling lookup instead of a scan. The alternative is a linear scan, which is simpler and fine until the lot has thousands of spots." That answer contains the choice, the reason, and the threshold at which the choice would change. Senior answers always carry the "until this stops being true" clause. A design without that clause is a design that has not been stress-tested by its own author.

    Part three: hold the interview. The interviewer has a script: requirements, entities, design, walkthrough, twist. A mid-level candidate follows it. A senior candidate owns the time budget. They state scope cuts out loud so the interviewer does not have to guess what is excluded. They say "let me walk the entry flow first and then I'll show you where the pricing seam goes" and then do exactly that. They redirect the inevitable detour ("what if we add valet parking?") with "good question, here is where that would land, but let me finish the core flow first." Driving the interview is not rudeness, it is delivery, and it is the most visible difference between the two levels.

    The class-design floor is unchanged. Entities, seams, patterns that fit, a walkthrough that works. None of that goes away. What the senior level adds is a second layer of attention, not a different kind of drawing.

    Real Interview Context#

    On the senior side of the table, the rubric is roughly three questions, and none of them are "did they know the domain." The first is whether the candidate can defend a design against an attack they did not prepare for. Interviewers do this by taking the candidate's own choices and attacking them: "you chose a HashMap for the URL store, what happens when it grows past memory?" The candidate who says "then it stops being true, and here is what I would move to" passes. The candidate who says "I would use Redis" without saying what Redis solves has given an answer that is worse than no answer.

    The second question is whether the candidate can admit when a trade-off has no winner. The movie booking system's seat lock is the classic: hold locks too long and you stall everyone behind one abandoned checkout; release too early and you double-sell. There is no right answer, only a chosen position and its cost. Senior candidates can state the position and the cost in one breath.

    The third is whether the candidate can scope. The senior candidate who says "I'm cutting reservations, analytics, and multi-region, here is why each is out" is demonstrating judgment. The candidate who designs all of them is demonstrating that they cannot say no, which is the most expensive trait an engineer can have.

    One more thing worth naming, because it is the least visible and the most consistent: seniors fail forward in public. A mid-level candidate who discovers mid-walkthrough that a method does not work the way they drew it tries to hide the discovery and paper over it. A senior candidate stops, names the problem, and revises in front of the interviewer, because that is what actually happens in a design review. The interviewer is not grading the absence of mistakes, they are grading the handling of them, and the candidate who says "wait, that ordering is wrong, the win check has to come after the jump resolves, let me fix that" has just demonstrated the exact behavior a senior is paid for.

    Common Mistakes#

    The first mistake is designing for the level instead of the requirements. Pattern-hoarding, extra layers, speculative abstractions. The interviewer asked for a rate limiter and you delivered a framework. The giveaway is that you cannot remove any single piece without the whole design looking like it lost a limb, because the pieces were added for balance, not for function.

    The second mistake is the rehearsed follow-up. The candidate has memorized the answer to "what if two elevators" from a blog post and delivers it verbatim, then cannot handle a variant. The interviewer asks "what if the elevator is at capacity" and the script is gone. Scripted depth is the same as no depth when it does not generalize, and interviewers detect it within one variation.

    The third mistake is freezing. A senior candidate revises. When the interviewer proposes a change that is better than the candidate's choice, the senior candidate adopts it and explains what it costs. The candidate who defends a bad choice past the point of reason, or who folds at the first push, both fail. The right move is revision with reasoning: "fair, if reservations are in scope then the spot lookup changes, and here is what I would do instead."

    Interview Perspective#

    A weak senior answer looks like a strong mid-level answer: correct classes, a working walkthrough, and nothing above that. Ask why the payment is a strategy and the candidate cannot say what second implementation would justify it. Ask about the race and the candidate has not noticed it. Ask what breaks at scale and the candidate says "cache it" without a mechanism.

    A strong senior answer is one where the interviewer's scripted questions all arrive as confirms, because the candidate already addressed them. The interviewer planned to ask about the seat-lock duration, and the candidate said "the lock duration is the trade-off, here is my position" before the question landed. The interviewer planned to push on the TreeMap and the candidate already stated the threshold where the scan wins. When the interviewer finally asks something the candidate has not anticipated, the candidate reasons it out loud, states the constraint, and revises. That arc, anticipated, reasoned, revised, is the senior interview in one paragraph.

    Knowledge Check#

    1. You present a design with three patterns: a strategy for pricing, an observer for the display, and a builder for the ticket. The interviewer asks you to remove the two that are not load-bearing. Which two do you remove, and what argument do you make for the one that stays?
    2. In the movie booking system, the interviewer asks "how long do you hold the seat lock?" Give the two positions, the cost of each, and the sentence you would use to state your position without hedging.
    3. You chose a HashMap-backed store for the shortener and the interviewer says "what happens at ten million keys?" Give the "until this stops being true" clause, the mechanism you would move to, and why that mechanism and not a different one.

    Key Takeaways#

    • Senior LLD is the same drawing with a different amount of justification attached to every mark.
    • Find the concurrency question before it is asked. It is the strongest signal in the round.
    • Every decision carries its rejected alternative and the threshold where it would change.
    • Own the time budget. State the scope, run the walkthrough, defer detours.
    • Revision with reasoning beats both rigidity and folding.

    What's Next#

    The senior posture, find the race, defend the trade-off, hold the interview, gets its first workout on the hardest classic in the book. The movie ticket booking system is where a seat becomes a lock and the whole design is the concurrency model.

    Want to Master Spring Boot and Land Your Dream Job?

    Struggling with coding interviews? Learn Data Structures & Algorithms (DSA) with our expert-led course. Build strong problem-solving skills, write optimized code, and crack top tech interviews with ease

    Learn more

    Last updated on Aug 19, 2026

    Was it helpful?

    Subscribe to our newsletter

    Read articles from Coding Shuttle directly inside your inbox. Subscribe to the newsletter, and don't miss out.

    Previous
    Design Splitwise
    Next
    Design a Movie Ticket Booking System — Handling Concurrency and Locking