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

    Why UML Matters in LLD

    Learning Objectives#

    1. Argue for the useful subset of UML, class, sequence, activity, state, component, and object diagrams, and against the useless weight of the full spec.
    2. Explain why a diagram is a thinking tool, not a documentation deliverable, and what drawing one forces you to decide.
    3. Use diagrams as a shared vocabulary in a design discussion or an interview, so two engineers disagree on substance instead of vocabulary.

    Introduction#

    UML gets a bad name from its worst fans and its worst enemies. The worst fans want every box, every arrowhead, every stereotype, and a CASE tool that generates code from the diagram. The worst enemies declare it dead and draw rectangles with freehand arrows. Both sides are wrong, and both sides miss the point. UML is a notation for describing software structure and behavior as pictures. That is all it is. It is not a methodology, it does not prescribe a process, and it has never successfully generated production code. What it is good at is forcing you to be precise about a design before you build it, and giving two engineers a shared language so they can argue about the design instead of about what the words meant. In an LLD interview, the subset of UML you actually need fits on one page. If you can draw a class diagram, a sequence diagram, and read a state diagram, you have more diagramming skill than most candidates who claim UML on their resume.

    Problem Statement#

    Here is the failure this chapter exists to prevent. Two engineers sit at a whiteboard. One says "so the order service calls the payment service, and it needs the customer details, and we should probably cache the tax calculation, and the web layer talks to the order service through a controller." The other engineer nods, walks away, and builds an order service that owns the payment call, the customer lookup, and the cache, because that is what the words sounded like. The first engineer reviews the code and finds the structure is completely different from what they agreed on. Nobody lied. The problem is that prose is ambiguous in exactly the places design decisions live. "Calls" does not say who owns what. "Needs" does not say whether the dependency is constructor-injected or looked up at runtime. "Talks to through a controller" does not say whether the controller returns the entity or a DTO. In a hallway conversation none of that is resolved, and it all gets resolved later, by whoever writes the code first, with no one checking. The same failure shows up in interviews. A candidate is asked to design a URL shortener and answers for fifteen minutes in a monologue, jumping between the API layer, the database schema, the redirect flow, and the cache, while the interviewer tries to hold the whole thing in their head. The candidate was thinking in pictures and talking in paragraphs, and the pictures never left their head. The interviewer cannot follow a structure that was never drawn, and the candidate is graded on a design the interviewer had to reconstruct from memory. Drawing is not decoration. It is how you make the design visible so it can be checked. A diagram that sits on the whiteboard for two minutes has already prevented the mismatch that prose would have shipped.

    Core Concept#

    Start with what UML actually is. The Object Management Group's full UML 2.x spec defines fourteen diagram types, split into two families. The structural diagrams describe the shape of the system: class, object, component, deployment, package, composite structure, and profile. The behavioral diagrams describe what the system does: use case, sequence, activity, state, communication, timing, and interaction overview. Nobody uses all fourteen. Anyone who tells you otherwise is selling something. The distinction that matters is between the diagrams that earn their place in a design discussion and the ones that exist for the spec's completeness. In practice, for low level design work, five types cover nearly every real need:

    • Class diagram, for the static structure, who has what, who owns what.
    • Sequence diagram, for one interaction between objects over time.
    • Activity diagram, for a flow with branches and decisions.
    • State diagram, for an object that changes state in response to events.
    • Component and object diagrams, for the module boundaries and the concrete instances at a moment.

    Use case and deployment diagrams occasionally show up in architecture discussions, and timing and communication diagrams are almost always academic. That is fine. You are not graded on diagram count. The reason to draw is that a diagram forces decisions prose lets you skip. Take a class diagram of a simple order flow. The prose version, "the order service uses a payment gateway," leaves open the multiplicity, the direction, the ownership, and the dependency style. The diagram version forces all of it. The arrow says the order service depends on the payment gateway. The open arrowhead or the absence of one says whether the dependency is through an interface. The multiplicity on the association says whether an order has one customer or many. The moment you try to draw it, you have to decide what you meant, and most design disagreements surface in exactly those decisions. The mapping to Java is direct, and this is why the notation is worth learning once instead of reinventing it every time. A class diagram is your Java source viewed from above.

    public class Order {
    private final Customer customer;
    private final List<OrderItem> items;
    public Receipt checkout(PaymentGateway gateway) {
        ...
    }
}

    A class diagram of that class captures three things the code already states: Order has a Customer and a list of OrderItem, and Order.checkout takes a PaymentGateway. The diagram is not additional information. It is the same information in a shape that lets you see the relationships, the direction of the arrows, the one-to-many, the dependency injection, all at once. The picture is faster to scan than the code when the question is "what depends on what." The deeper claim is that the diagram is a hypothesis and the code is the test. A class diagram is an argument about how the system should be shaped. The argument can be reviewed before a line of code exists, which is the entire point of designing before building. When the design is wrong, the diagram is where the error should be caught, because the cost of fixing an arrow on a whiteboard is five seconds and the cost of fixing a welded dependency is a refactor. There is a discipline that makes this work, and it is the opposite of the CASE tool fantasy. Draw the diagram, make the decision, and then let the code be the source of truth. Diagrams drift the moment they stop matching the code, and a drifted diagram is worse than no diagram, because it teaches the team the wrong structure. The fix is not round-trip engineering. It is drawing small, drawing rarely, and erasing without sentiment when the code moves on.

    Real Production Usage#

    The "UML is dead" crowd has a point about the formal tooling and none about the practice. Real teams draw diagrams constantly; they just stopped calling them UML and stopped being precious about the notation. Architecture Decision Records routinely embed a class or sequence sketch. Design reviews open with a diagram because nobody wants to walk twenty engineers through a prose description of the same flow. The notation that survives in the wild is the subset this chapter teaches, plus whatever local convention the team prefers. The tooling that matters in practice is lightweight. PlantUML and Mermaid render diagrams from text, which means the diagram lives in the repository next to the code, is diffable, and does not rot the way a whiteboard photo does. If you work in the Java ecosystem you have almost certainly seen Mermaid sequence diagrams in GitHub issues and PlantUML in wiki pages. Those are the realistic end states of UML in production: text-defined diagrams that are versioned and reviewed, not CASE tool exports. The other production use is documentation of systems you cannot read quickly. Spring's own documentation and Hibernate's documentation are full of diagrams, because a framework's dependency structure is exactly the thing a class diagram communicates fastest. Kafka's design documents describe the produce and fetch flows with sequence-style diagrams. When a system is large enough that no single engineer holds it all in their head, the diagram is the least-lossy way to hand the shape over.

    Common Mistakes#

    The first mistake is treating UML as a full methodology. Teams that adopt formal UML, every class in a diagram, every stereotype correct, every relationship signed, spend their time maintaining the diagram instead of building the system. The diagram becomes the source of truth and the code becomes a lagging artifact, and the whole thing collapses the first time someone ships a change without updating the picture. UML is a notation, not a religion. The second mistake is the inverse: rejecting all diagrams because UML tooling was awful. This is how you get the freehand-rectangle school of design, where every arrow is an unlabeled line and nobody knows which end points at the dependency. You do not have to adopt the full spec to adopt the precision. Two arrowhead conventions and a multiplicities label remove most of the ambiguity that freehand drawing leaves in. The third mistake is drawing the diagram for the diagram's sake and never using it to decide anything. A class diagram that was produced after the code was written, with no decision riding on it, is archaeology. It records the past. The diagram earns its keep only when a design question is on the table and the picture is what settles it.

    Interview Perspective#

    Interviewers do not ask you to recite UML notation. They ask you to design something, and the strong candidates draw while they talk. The candidate who puts a class diagram on the whiteboard in the first five minutes has already shown three things the rambler has not: that they can structure a system, that they can communicate the structure, and that they have a vocabulary for it. The weak answer to "how would you design a rate limiter" is a stream of features, "we'd have a rules engine, and a cache, and a counter, and some kind of sliding window," with no relationships stated. The strong answer draws the box for the rate limiter, draws the token bucket or sliding window as the algorithm inside it, draws the middleware that wraps the controller, and labels the dependency arrows. The interviewer can now ask questions against the picture, "who owns the counter," and the candidate can point at the diagram instead of re-explaining. The follow-up that separates the practiced from the parrot is "why do so many teams say UML is dead." The weak answer agrees and mumbles something about agile. The strong answer separates the notation from the ceremony. "The heavy tooling died, and good riddance. But the drawing survived everywhere. Teams still sketch the structure on a whiteboard before a refactor, ADRs still embed sequence diagrams. What died was round-trip engineering and the fourteen-diagram religion, not the two or three diagram types that actually communicate a design."

    Knowledge Check#

    1. A teammate says "we agreed the order service calls the payment service." During implementation you discover your interpretation differs from theirs. State the four design decisions a class diagram of that interaction would have forced you both to pin down.
    2. A senior engineer refuses to draw diagrams, saying UML is dead. Give the counterargument that separates the notation's useful core from the tooling's failures, using a specific diagram type and what it prevents.
    3. You are asked to design an e-commerce checkout in an interview. Write out the drawing plan: which two diagram types you put on the whiteboard first, what each one shows that the other cannot, and where you stop drawing.

    Key Takeaways#

    • UML is a notation for making structure and behavior visible, not a process, and the useful subset is about five diagram types.
    • A diagram forces the decisions prose lets you skip, multiplicity, direction, ownership, dependency style.
    • The diagram is a hypothesis, the code is the test, and the code is the source of truth once it exists.
    • In interviews, drawing while you talk is a measurable skill, and the whiteboard is where design thinking is shown, not the monologue.

    What's Next#

    This article argued for the notation without showing any of it. The class diagram is where the argument becomes concrete, and it is the diagram you will draw most often, in design reviews and interviews alike. The next article covers the boxes, the compartments, and the arrowheads that separate a real class diagram from a blob with lines, and what each arrow says about your Java code.

    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
    Designing for Testability : The Ultimate Proof of Loose Coupling
    Next
    Class Diagrams