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

    Using UML Effectively in Interviews

    Learning Objectives#

    1. Open a design question with the right diagram for the question being asked, without being told which diagram to use.
    2. Narrate the design while drawing, so the interviewer can follow the reasoning and interrupt it.
    3. Treat the diagram as a shared object, pointing at it to answer follow-ups and letting it reveal the gaps in your own design.

    Introduction#

    An LLD interview is not a notation quiz. No interviewer will fail you for the wrong arrowhead. But the whiteboard is where design is actually tested, and the diagram is the medium of the test. The candidate who draws while talking is graded on a visible design, one the interviewer can see and push against. The candidate who answers in paragraphs is graded on a reconstruction, a design the interviewer had to assemble from a monologue. The skill is not knowing UML. The skill is knowing which diagram answers which question, drawing the smallest version that carries the decision, and keeping the interviewer inside the picture the whole time. This article is the operating manual for that skill.

    Problem Statement#

    A candidate knows the material cold. They have built payment systems, they understand coupling, they can name the SOLID principles. The question is "design a rate limiter." For fifteen minutes they talk: token bucket here, sliding window there, a rules engine, a cache, Redis, a header for the remaining quota. The ideas are right. The interviewer is lost, because nothing was drawn, and a rate limiter is a set of relationships, who owns the counter, who reads the config, where the rejection happens, that are much easier to point at than to hold in the head. The candidate finishes, and the interviewer has to grade a design they had to reconstruct. The candidate is graded down not on ideas but on communication, which is the thing the interview is actually measuring. The opposite failure is just as common. A different candidate draws a beautiful class diagram, six boxes, every relationship arrow, multiplicities on every line. Then the candidate stops talking. The drawing is perfect and silent, and the interviewer has to drag the reasoning out of them one question at a time. The diagram carried no narration, so the design decisions it encodes were never stated, and the candidate is graded on a picture no one explained. Both failures are the same failure: the diagram and the conversation never connected. The material was there, the medium was wrong.

    Core Concept#

    The first decision is which diagram the question wants. It is almost never a guess. A structural question, "design a parking lot," "design a notification system," wants a class diagram first. A question about a critical path, "design the flow for a booking," wants a sequence diagram for the key interaction. A question with branching and parallelism, "design an order fulfillment pipeline," wants an activity diagram. A question about an object's legality, "design a vending machine," wants a state diagram. A question about module boundaries, "design the services for a large system," wants a component diagram. If you are not sure, the class diagram is the safe opening, because it is the structure most interviews are probing, and the behavior diagrams follow the structure naturally. The opening move is more important than most candidates realize. In the first few minutes, draw the top of the structure, four to six boxes, with names and relationship arrows, and say what each relationship means as you draw it. For the rate limiter, that is the middleware that wraps the controller, the rate limiter itself, the storage that holds the counters, and the config that holds the rules. Each box gets a sentence, "the limiter reads the config at startup, and the middleware checks the limiter before the request reaches the controller." You have now handed the interviewer a picture and a story, and every question that follows can be asked against it. The level of detail is where time is won and lost. Boxes get names. Arrows get directions. Multiplicity gets drawn only when it carries a decision, the 1 between an order and its items, the 1 to N between a customer and their orders. Attributes and method signatures are skipped unless the interviewer asks for them. Every extra detail costs a minute, and the interview is a budget. The interviewer who wants the fields will ask for them; drawing them uninvited is spending time on the least informative part of the design. The narration is the part that is actually graded. Every element you add should come with a reason, and the reason should be a design decision, not a description. "The controller depends on the service interface, not the implementation, so we can swap the storage," beats "and here the controller calls the service." The first is reasoning, the second is captioning. Interviewers grade the reasoning, and the narration is where they hear it. The diagram is a shared object, and the strongest move is pointing at it. When the interviewer asks "what happens if two requests hit at once," point at the counter and say "the increment happens here, in the store, atomically, so the limiter does not need a lock at the middleware level." The follow-up answers become a guided tour of the picture you drew, and the interviewer can see the answer rather than imagine it. The diagram is also a discovery tool, and this is the move that most separates the strong candidates. While you draw, you will hit the point where the structure does not fit, a missing collaborator, an illegal transition, a race. Say it out loud. "This design needs the token bucket to be shared across instances, so I need a distributed store here, which is new." The interviewer is not judging you for noticing the gap, they are rewarding you for it. Finding the hole in your own design, on the whiteboard, is the most expensive engineering skill, and a diagram is the cheapest way to demonstrate it. The shape of a strong interview answer is consistent. Ask the clarifying questions that define the scope, two or three, the scale, the clients, the failure tolerance. Then the structure, the class or component diagram, drawn and narrated in the first five minutes. Then the critical path, the sequence or activity diagram for the one interaction that is the point of the system. Then the edge cases, the points where your own diagram shows a gap. Then the tradeoffs, the honest statements about what you would not build. The diagram is not a step in that sequence, it is the medium the whole sequence happens in.

    Real Production Usage#

    The interview skill is the design review skill, and the interview is best treated as a compressed architecture review. The same opening move works in a real review: draw the structure in the first minutes, name the relationships, and let the diagram carry the discussion. The reason the move works in both rooms is the same, prose is a worse medium for structure than a picture, and the person with the picture controls the conversation. The other transfer is to written design. An architecture decision record that opens with a small diagram communicates its decision faster than one that opens with paragraphs, and the ADRs that get read are the ones that are scannable. Teams that adopt the habit, a diagram plus a few paragraphs of decision and tradeoff, are using the interview skill in production, and it produces the same result: a design that reviewers can see.

    Common Mistakes#

    The first mistake is drawing silently. A candidate who produces a perfect diagram and says nothing has hidden the reasoning, which is the entire point of the exercise. The rule: every box and every arrow you draw gets a sentence, and if you catch yourself drawing for a full minute without speaking, you have lost the room. The second mistake is over-drawing. Six boxes with every attribute, every method signature, and a note about the cache is a candidate spending the interview on the least informative details. The interviewer wants the relationships and the decisions, and the details are what they will ask for if they matter. Cut the attributes, keep the arrows. The third mistake is answering a behavior question with structure only. A candidate asked about the booking flow who draws a class diagram and stops has shown the skeleton and hidden the point, the interaction, the locking, the transaction. The structure is the opening, and the behavior diagram for the critical path is the answer to the question that was actually asked. The fourth mistake is an undefended arrow. A candidate who draws a relationship and, when asked why, says "that's just how it should be," has drawn without deciding. Every relationship in the diagram is a decision, the composition, the interface dependency, the direction, and a candidate who can defend each one is a candidate the interviewer remembers. The fix is to never draw an arrow you cannot give the reason for in one sentence.

    Interview Perspective#

    Interviewers grade three things, and it is worth naming them because they are not what most candidates prepare. First, can you structure a system, find the objects, the boundaries, the dependencies. Second, can you communicate that structure, in the medium the room uses. Third, do you notice the gaps, the concurrency, the failure modes, the missing collaborators. The diagram is how all three are observed. The weak answer to "design a booking system" is a monologue of features, a wall of words the interviewer converts into structure on their own. The strong answer is the drawing plus the narration, boxes, arrows, and the sentence of rationale for each, ending with the interviewer pointing at the diagram and asking about the lock on the seat, which was exactly the gap the candidate wanted them to find. The follow-up that surfaces the difference is "walk me through the critical path." The weak candidate re-explains from scratch, a second monologue. The strong candidate points. "Start here, at the booking request. The sequence diagram shows the seat check, the lock, the reservation, and the commit, and the failure path is here, the release on rollback." The interviewer sees the candidate navigate their own drawing, which is the entire skill. The harder follow-up is "what would you do differently." The strong candidate uses the diagram again. "I would not build the distributed rate limit across instances on day one, the single-node token bucket is the right first version, and the diagram shows the seam where the distributed store plugs in." The candidate is now discussing tradeoffs against a picture they control, which is the highest level the interview tests.

    Knowledge Check#

    1. You are asked to "design the flow for a ride-hailing trip from request to completion." State which diagram you draw first, which diagram shows the critical interaction, and which element in that diagram carries the concurrency question.
    2. An interviewer says "you are spending too much time on the details, step back." Name the three elements you are probably over-drawing, and state what should have been drawn instead.
    3. While drawing the class diagram for a design, you realize the design needs a collaborator you had not planned. Write the two or three sentences you would say out loud to the interviewer that turn the discovery into a strength rather than a stumble.

    Key Takeaways#

    • Pick the diagram by the question, structure first, then the behavior diagram for the critical path.
    • Draw the smallest version that carries the decisions, names and arrows, not attributes and signatures.
    • Narrate every element with a reason, and answer follow-ups by pointing at the picture.
    • Use the drawing to find the gaps in your own design, and say the discovery out loud.

    What's Next#

    The technique article ends at the rules for using diagrams well. The last article in the chapter is the mirror image, the rules for using them badly. Common UML Mistakes to Avoid collects the failures, the wrong arrow, the drifted diagram, the over-drawn box, and the notation that teaches the wrong design, and it is the article that turns the whole chapter into a review checklist.

    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 18, 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
    Component and Object Diagrams
    Next
    Common UML Mistakes to Avoid