Low-level System Design (LLD) Handbook
Want to get good at Low Level Design? You've found the right place to start. This handbook covers everything from core OOP principles to advanced LLD patterns used in real production systems.
Low-level System Design (LLD) Handbook
WWW.CODINGSHUTTLE.COM
Handbook Chapters
Follow our structured learning path. Explore all the chapters and in-depth topics covered in this handbook.
What is Software Design?
This article explains that software design is the set of decisions about structure and communication, not the diagrams that describe them, and that a codebase always carries a design whether anyone chose one or not. Its strongest claim is that the real design is whatever the code enforces at runtime, making the drawing optional and the decision mandatory.
High-Level vs Low-Level Design — Drawing the Boundary
This article explains that high-level and low-level design are not documents but two scopes of decision, split by whether a choice touches the whole system or a single component. Its strongest claim is that the boundary is not fixed and moves with your scale, so the same question can be high-level in one organization and low-level in another.
Software Architecture vs Software Design
This article explains that architecture and design are separated by reversibility and scope, not by diagram type, and that architecture emerges from the sum of decisions rather than from a top-level drawing. Its strongest claim is that an architect is whoever catches the high-stakes decision in a low-stakes conversation, not whoever owns the box diagram.
Functional vs Non-Functional Requirements
This article explains the distinction between functional requirements, what a system does, and non-functional requirements, the standard it meets while doing it, and why the latter almost always decides the architecture. Its strongest claim is that a requirement without a number is a wish, and that "it works" is a test failure when the real constraint was never written down.
The Software Design Process and Design Thinking
This article explains the software design process as an iterative loop rather than a one-shot waterfall, mapping the five phases of design thinking to concrete engineering activities. Its strongest claim is that the define phase decides everything, and that most design failure is not bad structure but a misread problem that was never stated out loud.
Characteristics of Good Software Design
This article defines the characteristics of good software design through the lens of how cheap change is, led by coupling and cohesion, not how neat the code looks. Its strongest claim is that maintainability is a label for one real lever, and the honest test of a design is "how many files do I touch when behavior changes."
Common Software Design Mistakes
This article lists the five design mistakes that keep appearing in production code, from god objects to premature abstraction, and argues they are mostly one deep problem at different sites. Its strongest claim is that the fix that lasts is made at the review, when a ten-minute decision is cheaper than the refactor it prevents.
How to Read and Write Design Documents
This article explains how to write and read design documents so that decisions, not structure, are what survive the review. Its strongest claim is that the sections teams skip, the non-goals and the alternatives, are precisely the ones that prove a real decision was made.
The Framework: How to Approach LLD Problems
This article condenses the whole chapter into an eight-step framework for attacking any LLD problem, from restating the scope to re-reading the non-functional requirements. Its strongest claim is that the steps are a dependency order, not a checklist, so the skipped step, not the hard one, is where every mistake hides.
Introduction to OOP and the Java Memory Model
This article explains how object-oriented programming maps onto the Java memory model, where the stack holds local values and the heap holds every object, connected by references. Its strongest claim is that Java passes both primitives and references by value, so the only real bug in most Java systems is a shared object reached through a reference that escaped.
Classes, Objects, and the this Keyword
This article explains the split between a class, the blueprint, and an object, the live instance, and argues that this is simply the hidden receiver reference the JVM passes into every instance method call. Its strongest claim is that one compiled method body serves every object of a class, and the only thing that changes between calls is which heap object this points at.
Constructors and Object Initialization
This article explains that constructors are the birth ceremony of an object, the place where an allocated heap block is turned into a valid instance, and walks the exact order of initialization. Its strongest claim is that every way to create an object should delegate to one canonical constructor, because the number of places that can initialize a field wrong should be exactly one.
Encapsulation and Access Modifiers
This article explains encapsulation as the bundling of state and behavior with the state hidden behind access modifiers, and walks exactly who can see each of the four levels of visibility. Its strongest claim is that a getter and setter on every field is a public field with better grammar, and that real encapsulation exposes behavior, not data.
Abstraction : Interfaces vs Abstract Classes
This article explains abstraction as hiding mechanism behind contract and separates the two Java tools, the stateless interface and the state-holding abstract class, by what each one can carry. Its strongest claim is that the single-superclass rule makes the choice expensive, so you should default to an interface until shared state genuinely forces an abstract class.
Inheritance and Its Types
This article explains inheritance as the is-a mechanism, what a subclass actually inherits, and the four shapes it can take, including why Java refuses multiple class inheritance. Its strongest claim is that inheritance is a model of kinds, not a way to reuse code, and the is-a test should gate every extends you ever write.
Polymorphism : Compile-Time vs Runtime
This article explains the two flavors of polymorphism, compile-time overloading decided by the compiler and runtime overriding decided by the JVM, and why only the second powers real design. Its strongest claim is that a caller written against the parent type works for every future child type, and that an instanceof chain is usually the polymorphic method the code forgot to write.
Association, Aggregation, and Composition
This article explains the three has-a relationships, association, aggregation, and composition, and reduces them to one question: who owns the other object's lifetime. Its strongest claim is that Java enforces none of it, so composition is a discipline of private fields and parent-created children, and that whoever creates a resource is the only one allowed to close it.
Dependency Relationships
This article explains the dependency, the thinnest relationship in the object model, a compile-time fact that carries no lifetime meaning, and shows that its direction is a design choice. Its strongest claim is that depending on abstractions instead of concrete classes, with dependencies supplied through constructors, is the move that makes a system swappable and a test injection possible.
Generics and Type Safety
This article explains generics, the feature that lets the compiler check what a collection holds and erases every type argument before the JVM runs. Its strongest claims are that erasure is the model behind every generics rule, that generic types are invariant, and that a raw type silently reintroduces the exact runtime failure the feature was built to remove.
The Golden Rule : Composition Over Inheritance
This article explains the golden rule, favor composition over inheritance, and grounds it in the failure of deep hierarchies and subclasses that disable their parents. Its strongest claim is that the is-a test earns every extends, that delegation replaces reuse-by-inheritance, and that is-a belongs to interfaces while has-a belongs to fields.
Introduction to Design Principles
This article explains design principles as bets about the cost of change and organizes them into the change, contract, and restraint families. Its strongest claim is that a principle quoted without a specific change in mind is a performance, not an argument, and that the real skill is holding the cost model, not memorizing the rules.
Single Responsibility Principle
This article explains the Single Responsibility Principle as one reason to change, not one thing to do, and shows how the reason is found by asking who asks for the change. Its strongest claim is that splitting a class by responsibility usually reveals a missing collaborator, and that line count is a symptom, not the definition.
Open-Closed Principle
This article explains the Open-Closed Principle as growth by addition, new classes rather than new edits, behind the one seam the stable flow depends on. Its strongest claim is that closing a module costs indirection, so you close it only against the axis of change that actually exists, found by watching where the edits land.
Liskov Substitution Principle
This article explains the Liskov Substitution Principle as a behavioral contract the compiler cannot check, and the three ways a subclass breaks it. Its strongest claim is that a subclass that has to fight its parent is a refused bequest, and that the fix is composition, not a cleverer override.
Interface Segregation Principle
This article explains the Interface Segregation Principle as the client-side version of SRP, and how a fat interface couples every dependent to methods it does not use. Its strongest claim is that an implementer throwing UnsupportedOperationException is the tell, and that default methods hide the fatness instead of removing it.
Dependency Inversion Principle
This article explains the Dependency Inversion Principle as a claim about arrow direction, with the policy owning the abstraction and the details implementing it. Its strongest claim is that injection is a mechanism and inversion is a principle, and that an interface placed beside the implementation defeats the inversion.
DRY, KISS, and YAGNI Principles
This article explains DRY, KISS, and YAGNI as the restraint family, three bets against the cost of overbuilding. Its strongest claim is that DRY is about duplicated knowledge that changes together rather than similar text, and that YAGNI is a cost comparison that loses when the future is known to be coming.
High Cohesion and Loose Coupling
This article explains high cohesion and loose coupling as the inside and the outside of a module, and how the two interact when a class does too many jobs. Its strongest claim is that most coupling complaints are cohesion problems in disguise, and that the coupling that matters is the blast radius of a change, not the number of classes.
Law of Demeter
This article explains the Law of Demeter as talk only to your immediate friends, and separates the real violation from the harmless dot chain. Its strongest claim is that the dot count is a proxy for the real crime, knowing the shape of the object graph, and that the delegation the law causes is the point, not the cost.
Separation of Concerns and Information Hiding
This article explains separation of concerns as splitting code by what it is for, and information hiding as concealing the details that change. Its strongest claim is that separation creates the boundaries and hiding makes them honest, and that the repository is both at once, the vendor hidden from the business code.
Designing for Testability : The Ultimate Proof of Loose Coupling
This article explains testability as the three seams of construction, control, and observation, and why a class you can test in isolation is loosely coupled by definition. Its strongest claim is that mocking a concrete class is a patch, not a proof, and that a hard-to-test class is the design confessing.
Why UML Matters in LLD
This article explains why UML survives as a small set of diagram types that force decisions prose leaves ambiguous, and why the notation is a thinking tool, not a ceremony. Its strongest claim is that the heavyweight tooling is dead and the drawing survived, and that a diagram is a hypothesis the code tests.
Class Diagrams
This article explains the class diagram as the structural workhorse of low level design, with the box and the relationship arrows mapped to Java. Its strongest claim is that arrow direction is the diagram's honesty, and a wrong-end arrowhead teaches the inverse of the truth.
Sequence Diagrams
This article explains the sequence diagram as the only design tool that carries time, with lifelines, messages, returns, and activation bars read top to bottom. Its strongest claim is that interaction order is design information no other diagram captures, and the arrowhead is the difference between blocking and not.
Activity Diagrams
This article explains the activity diagram as the flow without an owner, with guarded decisions and fork-and-join bars that make parallelism visible. Its strongest claim is that an unlabeled branch is a hidden else, and a fork without the matching executor is a diagram lying about concurrency.
State Diagrams
This article explains the state diagram as one object's possible conditions and the legal moves between them, with states, events, transitions, and guards. Its strongest claim is that a status field is a state machine nobody drew, and the absent arrows are where the design rules live.
Component and Object Diagrams
This article explains the component and object diagrams as the two scale extremes, the module boundaries with ball-and-socket interfaces, and the snapshot with underlined instances. Its strongest claim is that a component dependency is honest only through an interface, and the underline is all that separates an instance from a class.
Using UML Effectively in Interviews
This article explains how to use diagrams in an LLD interview, choosing the right diagram for the question, drawing the smallest version that carries the decision, and narrating while you draw. Its strongest claim is that the interview is a design review, and pointing at your own diagram is the strongest answer available.
Common UML Mistakes to Avoid
This article explains the failure catalog of UML, the lying arrow, the drifted diagram, and the box that over-draws. Its strongest claim is that every diagram element must be checkable against the code, and a drifted diagram is worse than none, because it teaches the wrong structure.
What Are Design Patterns?
This article explains what a design pattern is, the four parts of name, problem, solution, and consequences, and how a pattern differs from a library or an algorithm. Its strongest claim is that patterns follow problems, never precede them, and that the name is what turns a re-invented shape into shared vocabulary.
History and the Gang of Four
This article explains where design patterns came from, the architecture and Smalltalk lineage, the 1994 Gang of Four book, and why its twenty-three patterns still name the shapes you draw. Its strongest claim is that Java absorbed much of the catalog, so the behavioral patterns became syntax while the structural ones are still written by hand.
Categories of Design Patterns
This article explains the three families of the twenty-three patterns, creational, structural, and behavioral, and the question each family answers. Its strongest claim is that the families are the index to the catalog, and that seeing the pattern in its family tells you its problem before you read its description.
How to Choose a Design Pattern
This article explains how to choose a design pattern by naming the instability first, building a shortlist, and breaking ties with consequences. Its strongest claim is that a pattern is selected by the problem sentence, never by matching the diagram, and that the YAGNI guard runs last, refusing the pattern when the instability is not real.
Anti-Patterns and Common Misuse
This article explains the anti-patterns tied to the design patterns, the God Object, the Singleton abuse, the pattern spam, and the smell test that catches them. Its strongest claim is that an anti-pattern is a pattern applied where its problem is false, and that the immutable singleton survives review while the mutable one is removed.
Design Patterns Interview Strategy
This article explains the interview strategy for the design pattern catalog, leading with the instability and the constraint and letting the pattern fall out last. Its strongest claim is that the pattern is the conclusion of the argument, and that saying "no pattern" with the YAGNI guard reads as experience, not ignorance.
Creational Patterns Overview
This article explains what the five GoF creational patterns share, why direct new becomes a liability once construction decisions vary, and how to match each pattern to the specific construction problem it solves. It argues that creational patterns are deferred decisions, not decoration, and that most misuse comes from adding indirection before a second variant actually exists.
Singleton Pattern: Including Thread-Safe and Bill Pugh Implementations
This article explains what a Singleton must actually guarantee under concurrency and walks through the naive, synchronized, double-checked-locking, and Bill Pugh implementations. Its central claim is that the Bill Pugh holder idiom is the only Java answer that gets laziness, thread safety, and low call cost all at once, and that the pattern itself should be a fallback rather than a default.
Factory Method Pattern
This article explains Factory Method as a creation seam that subclasses override, not as a factory object, and shows how it keeps callers coupled to an abstraction instead of a concrete class. Its central claim is that the pattern is really Template Method in disguise, and that the override seam, not the act of creating, is what gives it lasting value.
Abstract Factory Pattern
This article explains Abstract Factory as the pattern that guarantees a family of related objects stays consistent, using a UI toolkit with Windows and macOS variants as the running example. It argues that the family guarantee is the entire reason the pattern exists, and that its rigid interface is the price you pay for that guarantee.
Builder and Fluent Builder Pattern
This article explains the Builder pattern as the answer to telescoping constructors and unlabeled argument lists, with an immutable Computer as the running example and a fluent chain in Java. It argues that build() is the only legitimate home for validation and defaults, and that a builder is justified by optional fields and policy, not by object size.
Prototype Pattern
This article explains the Prototype pattern as copying a known object instead of constructing a new one, centered on the distinction between shallow and deep copies. Its central claim is that Object.clone() is shallow by default and therefore dangerous for any mutable field, and that the decision of what to share and what to copy is the entire real content of the pattern.
Factory vs Builder : When to Use Which
This article explains how to tell Factory and Builder apart by asking what decision the code hides, not by memorizing diagrams. It argues that a factory whose parameter list grows with optional settings is a builder in disguise, and that the correct resolution when an object has both axes is to compose the two patterns rather than fuse them.
Real-World Usage of Creational Patterns
This article maps all five creational patterns onto the JVM, Spring, and Hibernate, teaching you to recognize them by shape instead of by diagram. Its strongest claim is that a Spring singleton bean is not the Singleton pattern at all, and that hand-rolling creational patterns inside a container usually duplicates work the framework already does.
Structural Patterns Overview
This article explains the seven structural patterns as different answers to the same question, how existing objects get arranged without breaking their consumers. Its central claim is that the patterns are distinguished by intent, not shape, and that Adapter, Facade, and Proxy are the three intents engineers most often blur.
Adapter Pattern
This article explains the Adapter pattern as a translator that sits between code you own and code you cannot change, using a legacy messenger SDK as the running example. It argues that the object adapter is the only serious choice in Java, and that the pattern belongs strictly at external boundaries, never between classes you control.
Bridge Pattern
This article explains the Bridge pattern as a proactive split of two independently growing dimensions into parallel hierarchies joined by a single reference. It argues that the class grid whose names glue two concepts together is the diagnostic, and that the timing test, proactive split versus reactive adapter, is what separates Bridge from Adapter.
Composite Pattern
This article explains the Composite pattern as a uniform interface that lets a client treat a single file and a whole directory tree identically, with recursion living inside the container. It argues that the real design decision is how uniform the interface should be, and that the leaf's throwing methods are a deliberate trade, not a flaw.
Decorator Pattern
This article explains the Decorator pattern as wrapping an object in layers of same-interface objects, with the coffee add-on stack as the running example. It argues that the subclass explosion is the diagnostic, and that the identity and ordering problems are what separate people who have used the pattern from people who have only drawn it.
Facade Pattern
This article explains the Facade pattern as a single front door over a multi-class subsystem, with an order placement workflow as the running example. It argues that a facade must orchestrate and delegate without deciding policy, and that a facade which starts hiding its subsystem or returning subsystem types has stopped being one.
Proxy Pattern
This article explains the Proxy pattern as a same-interface stand-in that controls access, covering the virtual, protection, and remote jobs it does. Its central claim is that Proxy controls access while Decorator adds behavior, and that naming that intent is what separates a real proxy from a mystery wrapper.
Flyweight Pattern
This article explains the Flyweight pattern as sharing immutable intrinsic state across many instances while keeping per-use state outside, using a text renderer's glyphs as the running example. It argues that the intrinsic-extrinsic split and the immutability rule are the entire pattern, and that for most codebases the pattern is a premature optimization until measured.
Adapter vs Facade vs Proxy
This article explains how to tell Adapter, Facade, and Proxy apart with three verbs, change, simplify, and control, instead of memorized diagrams. It argues that naming a wrapper's intent is the entire skill, and that real wrappers often serve two intents at once, each of which must be named.
Real-World Usage of Structural Design Patterns — How Spring Security Uses Filters and Proxies
This article explains how Spring Security is built from the structural patterns, tracing a request through DelegatingFilterProxy, FilterChainProxy, and the security filter chain. It argues that the framework's magic is the proxy pattern, and that every self-invocation gap, final-class gap, and filter ordering bug is the proxy's known edge.
Behavioral Patterns Overview
This article explains the eleven behavioral patterns as answers to how objects cooperate at runtime, grouped into four clusters that map to the failures they remove. The failure it fixes is hardcoded behavior, and recognizing that failure matters more than recalling a diagram.
Strategy Pattern
This article explains the Strategy pattern as moving algorithm branches behind an interface and choosing the variant at the wiring point. It argues the strategy must stay dumb and the decision must live at the composition root.
Observer Pattern
This article explains the Observer pattern as a one-to-many broadcast with the observer detached from the subject. It argues that the broadcast, not the listener, is the whole point of the pattern.
Command Pattern
This article explains the Command pattern as packaging an action into an object so it can be queued, replayed, and undone. It argues that the pattern pays off exactly when the action needs a life beyond its call site.
Chain of Responsibility
This article explains the Chain of Responsibility pattern as passing a request down an ordered list of handlers until one claims it. It argues that the terminal handler and the deliberate ordering are what make a chain correct.
Template Method Pattern
This article explains the Template Method pattern as a base class owning the algorithm's order in a final method. It argues that the final skeleton is the invariant and that composition often beats the template when the sequence is not stable.
State Pattern
This article explains the State pattern as turning a growing switch into state classes that each own the legal behavior in the current state. It argues that illegal transitions are the whole value, and any object whose behavior changes over its life is this pattern.
Mediator Pattern
This article explains the Mediator pattern as a hub that replaces a web of direct references, with a checkout dialog as the example. It argues the mediator routes and sequences without deciding business policy, earning its keep only for a genuine tangle.
Iterator Pattern
This article explains the Iterator pattern as the cursor that moves the walk out of the collection, letting one loop serve any storage layout. It shows the cursor and fail-fast contracts, and how the typed generic form catches wrong-type errors at compile time.
Memento Pattern
This article explains the Memento pattern as a sealed snapshot, with an undoable document as the example. It shows how the opaque token keeps the caretaker from ever coupling to the originator's internals.
Visitor Pattern
This article explains the Visitor pattern as a way to detach operations from a stable class hierarchy, using an order system as the example. It argues that the pattern earns its place when the type set stays closed while the operations keep growing.
Strategy vs State — Key Differences
This article explains the difference between Strategy and State by one deciding question: a choice versus a condition. It argues that the state restricts legal operations while the strategy tunes a single decision, and that the two share the same shape.
Real-World Usage of Behavioral Patterns
This article explains how behavioral patterns appear together in real systems, combining a Chain, Strategies, and a Mediator in one flow. It argues that production composition, not isolated diagrams, is the real test.
Introduction to Domain Modeling
This article explains what a domain model is, a map of the business rather than a copy of the database, and why the model owns the rules. It argues that a rule enforced by the object itself is the only one that cannot be bypassed.
Identifying Entities and Value Objects
This article explains the split between entities and value objects by one test, which cares who it is or what it is. It argues that value objects are immutable with structural equality, and modeling every value as an entity is a mistake.
Aggregates and Aggregate Roots
This article explains the aggregate as a consistency unit, with one root and a boundary that enforces its invariants. It argues that aggregates stay small and separate, and that separate aggregates reference each other only by id.
Domain Services
This article explains when a business rule belongs in a domain service using a money transfer across two accounts. It argues that the test is whether the rule describes one object or a transaction between objects.
Repositories in Domain Design
This article explains the repository as an interface in the domain representing an aggregate as a collection, with the persistence implementation behind it. It argues that the domain depends on the interface and never the storage, and stays testable without a database.
Business Rules Modeling
This article explains business rules as three kinds, invariants, constraints, and derivations, each placed on the object that owns the fact. It argues that a rule with a guard on its operation cannot be bypassed, where a rule duplicated in callers is missed.
Domain Events
This article explains the domain event as a past-tense record of a fact, raised by the aggregate that caused it, with the consequence left to a listener. It argues that the aggregate records and never calls the reaction, and the event carries stable values.
Designing Rich vs Anemic Domain Models
This article explains the rich model, which places rules on the object owning the data, against the anemic model with rules pushed into the service. It argues that method names are the tell, and that anemic is a smell only for the domain object.
Putting It Together — Full Domain Model Walkthrough
This article explains one full model, an order aggregate, a customer, a domain service, a repository, and the submitted event, and walks a checkout through them. It argues the model holds because each rule lives on the object that owns it, and the service coordinates.
Introduction to API Design — Principles and Goals
This article explains what an API is, a contract with consumers you do not control, and frames its two failure modes: the overloaded endpoint and the mirror-of-the-database endpoint. It argues that the interface outlives the code and that additive changes are the only cheap ones.
REST Principles and Resource Modeling
This article explains REST as resources and verbs, the URL the noun, the method the operation, a token that stays guessable. It argues verbs in the path are RPC in a REST disguise, and statelessness is the price of scale and retryability.
DTO Design and Mapping Strategies — MapStruct and Jackson
This article explains the DTO as a transport shape and the mapping, in MapStruct and shaped by Jackson, that turns a domain object into the wire. It argues the DTO keeps the domain and the contract apart, and skipping it returns the entity whole.
Request and Response Design
This article explains request and response design as one contract, the status code, the Location and caching headers, and the body answering together. It argues a create returns 201 with the Location, and a reply that leaves you guessing fails its first user.
Input Validation Design
This article explains input validation as three gates, syntax on the DTO, invariants on the domain, and cross-object rules in the service. It argues the same rule appears once, on the layer that owns it, and a validation is not a domain invariant.
Error Handling and Standardized Error Responses
This article explains error handling as one standardized envelope, a stable code, a message, and a traceId from a single global handler. It argues that a client branches on the code, not the message, and leaking internals wastes the contract.
Pagination, Filtering and Sorting
This article explains pagination as a bounded walk, the cursor when the set changes and the offset when it is static. It argues an offset on a live table drifts, and the cursor on a stable key holds.
API Versioning Strategies
This article explains API versioning as carrying two shapes at once and retiring the old contract with a dated deprecation. It argues that additive-first takes you far, and a deprecation without a date is only a threat.
Idempotency in APIs
This article explains idempotency as keyed de-duplication, the result stored under a client key, the duplicate replayed verbatim. It argues a POST is not safe, so the retry needs a key, and the key must commit atomically with the write.
API Security Basics
This article explains API security as two ordered checks, authentication who is calling, then authorization what they may do. It argues that a verified token is the only source of identity, not a role the request body claims.
Designing Internal vs External APIs
This article explains the internal and external API as two contracts, a lean fast surface for your own services and a stable, versioned one for the world. It argues that one core with two thin adapters is right, and one contract for both breaks either.
Introduction to Persistence Design
This article explains persistence as three layers, storage engine, access layer, and domain logic, and why most bad persistence is a leak between them. It argues that calling the database's shape is the real design decision, not the framework you used to get there.
The Repository Pattern — Spring Data JPA Under the Hood
This article explains that a repository is a contract for a framework-generated proxy and that save() registers entities with the persistence context rather than writing SQL immediately. It argues that reading a repository method like the query it emits is what keeps Spring Data from becoming a black box.
DAO vs Repository Pattern
This article explains the difference between a DAO's physical storage access and a repository's domain-facing access, and argues the repository sits above the DAO while the DAO stays hidden. It argues that using the two as interchangeable terms is exactly how storage leaks into the entire domain.
Transactions and ACID Properties
This article explains what each letter of ACID actually guarantees and when a Spring @Transactional boundary silently does nothing. It argues that database consistency only ever protects declared constraints and never your business rules, and that a swallowed exception quietly voids the transaction's whole warranty.
Unit of Work Pattern
This article explains the Unit of Work behind JPA's persistence context, tracking changed entities and writing the diff at commit. It argues that a loop of save() calls is never a loop of SQL, and that the flush boundary, not the save, is the boundary nobody remembers.
Optimistic vs Pessimistic Locking
This article explains optimistic locking, which checks a version at write time and fails late with a retry, and pessimistic locking, which takes the row at read time and blocks early. It argues that choosing between them is a bet on contention rate, and that a retry storm over a hot row is worse than the wait it avoided.
Lazy Loading vs Eager Loading and the N+1 Problem
This article explains lazy and eager loading and traces the N+1 query explosion to JPA's per-relationship defaults. It argues that a per-query fetch join or entity graph, not a global eager flag, is the real fix, and that the misread defaults are what hide the source of the query storm.
Caching Fundamentals
This article explains a cache as a second store built on four dials, hit rate, TTL, capacity, and invalidation, and the bounded staleness each trade costs. It claims that caching a rarely-repeated slow query is a tax, and that naming the stale window as a chosen trade is the position every design must take.
Write-Through vs Write-Back vs Cache-Aside
This article explains write-through, write-back, and cache-aside by their write ordering and the inconsistency window each tolerates. It argues that cache-aside is the correct default because it invalidates on write rather than updating, and that write-back's crash window makes it unfit for money-bearing workloads.
Persistence Design Best Practices
This article explains the chapter's tools as five persistence habits, every invariant owned, short transactions, one truth on the write path, and a schema that earns its shape. It argues that the framework default is a decision made for you, and that a layer survives production only when its choices were deliberate.
Designing for Data Consistency in Concurrent Systems
This article explains how to tell the consistency problems one database still arbitrates from the ones a distributed tool must fix, and names idempotency and the transactional outbox as the two reliable answers. It argues that a single database already orders a shared row, and that a distributed lock is usually invented precisely where the database stopped deciding.
Introduction to Concurrency — Threads vs Processes
This article explains the line between a process and a thread as a question of memory ownership. It argues that threads exist to overlap I/O with compute, and that the heap sharing that makes them cheap is the same sharing that turns a simple counter wrong.
Thread Lifecycle
This article explains the six Java thread states and the transition each one needs. It argues that reading a thread dump is a matter of asking whether the stuck thread waits for a lock, a signal, or a timer, and that the wrong guess is usually the difference between the wait and the notify.
Thread Class vs Runnable vs Callable
This article explains the difference between Thread, Runnable, and Callable, and which one carries a value or an exception back. It argues that work with a result must be a Callable, that run() returns void and cannot throw, and that extending Thread is the least flexible shape of the three.
The Executor Framework and Thread Pools
This article explains the executor framework and how a thread pool turns a flood of tasks into a bounded set of workers and a waiting queue. It argues that the queue is the control that decides whether a pool ever grows, and that the size of a CPU pool is how many cores you have been willing to use.
Synchronization and Locks
This article explains synchronized as both a mutual-exclusion lock and a memory barrier, and how a monitor held on one object guarantees only one thread sees a section at a time. It argues that lock conflicts live in the coverage, not the keyword, and that the smallest block on a stable object beats a whole method.
ReentrantLock and ReadWriteLock
This article explains ReentrantLock as a manually controlled lock and ReentrantReadWriteLock as a lock that lets many readers in while writers wait. It argues that the extra verbs are bought with the duty to unlock, and that a read-write split only earns its overhead when reads truly dominate the writes.
Semaphores and Countdown Latches
This article explains the Semaphore as a fixed-count of permits that limits how many threads can be inside a section, and the CountDownLatch as a gate that opens when a set of events has drained to zero. It argues that both replace a personal lock with a shared count, and that each leaks guarantees when you mishandle the permits or the count.
Concurrent Collections — ConcurrentHashMap and Friends
This article explains how the concurrent collections, led by ConcurrentHashMap, deliver thread safety by locking small and letting reads run in parallel. It argues that the trade for speed is a weaker global view, so compound read-then-write still needs the atomic helpers, and the map does not make your own composition correct.
Future and CompletableFuture for Async Design
This article explains Future as a handle for a value that completes later and CompletableFuture as the same idea with callbacks so no thread blocks on get. It argues that the gain comes from composing stages rather than holding, and that a timeout and an exception path are part of the design, not an afterthought.
Thread Communication — Wait, Notify, NotifyAll
This article explains wait, notify, and notifyAll as a low-level handshake where a thread parks on a monitor and a producer wakes it. It argues that correctness lives in the loop and the notifyAll, and that these fragile pieces are why a BlockingQueue and a latch hide the same chore behind a safer face.
Common Concurrency Problems — Deadlock, Starvation, Race Conditions
This article explains the three thread problems: deadlock as a circular wait on held locks, livelock as threads that keep moving without progress, and starvation as a wait that never ends. It argues that a deadlock breaks with a consistent lock order, and that the other two need fairness and a structure that stops the barge.
Designing Thread-Safe Classes
This article explains that a thread-safe class is a contract backed by one of three strategies: immutable state, thread-confined state, or state guarded by a lock. It argues that the design must name the strategy before the code, so a shared mutable field without a guard is a known bug and not a surprise.
Concurrency Design Best Practices
This article explains the concurrency practices that keep a multithreaded system steady: avoid sharing, use the narrowest tool, keep critical sections short, and time every wait. It argues that most concurrency bugs come from choosing the wrong level of the stack, and that a lock is the last resort, not the first line.
Introduction to Event-Driven Architecture
This article explains event-driven architecture as trading synchronous calls for the publishing of past-tense facts that consumers react to on their own schedule. It argues that the model buys availability and a replayable record at the price of eventual consistency, and that a command dressed as an event is the most common first failure.
The Publisher-Subscriber Model
This article explains the publisher-subscriber model as the three roles and the two delivery modes, a topic that broadcasts to every subscriber and a queue that hands each message to one worker. It argues that Kafka's topic plus consumer group is the deciding power because it covers both, and that mixing the two semantics is the cheapest way to lose or duplicate an event.
Observer Pattern vs Pub-Sub — Where They Differ
This article explains the difference between the observer pattern and pub-sub as a single fact, where the subscriber's reference is held, in the subject or in the broker. It argues that the shared fan-out hides a real coupling difference, and that dragging an observer into a cross-process problem without a broker is a failure and not a replay.
Event Modeling — Designing Good Events
This article explains how to model an event as a timestamped, immutable, keyed delta that carries what the consumer needs and never a reference or a full snapshot. It argues that the most important test of an event is that a subscriber can rebuild its own view from the payload alone, and that events evolve by version or a new type, never by editing the old fact.
Message Queues — Concepts and Internal Design
This article explains the internals of a message queue as a partitioned keyed log with an offset and a consumer group, the pieces that give ordering per key, parallelism across members, and at-least-once replay. It argues that the position of the commit is the entire delivery policy, and that an idempotent consumer is the non-negotiable price of at-least-once.
Eventual Consistency and What It Means for Object Design
This article explains eventual consistency as the moment between an event and the projections that consume it, and shows how to design the read side so that lag is safe. It argues that the read model must be an idempotent, rebuildable fold over the event log, marked with an as-of time, rather than a snapshot that pretends to be the truth.
Event Sourcing — Concepts and When to Use It
This article explains event sourcing as making the event log the source of truth and the current state a derived fold of it, which buys a complete audit and temporal queries. It argues that the pattern is right for a ledger where history is the product, and a genuine tax where the current state is all that matters.
CQRS — Command Query Responsibility Segregation
This article explains CQRS as separating the write model, a command and an aggregate, from the read model, a view and a projection, so each takes the shape its work demands. It argues that CQRS is justified by a reads-and-writes load that diverges, and that both a read replica and a source projection are valid reads, so CQRS does not depend on event sourcing.
Common Pitfalls in Event-Driven Systems
This article explains the common failure set of an event-driven system: lost events, duplicates, out-of-order deliveries, and a drifting read view. It argues that each has a concrete repair, an outbox, an idempotent consumer, a keyed stream, and a marked rebuild, and that most incidents trace to one missing repair, not to the broker.
Logging Fundamentals and Best Practices
This article explains the production log line as a structured record: template, fields, MDC, and a preserved stack. It argues failures come from deciding level and schema ad hoc at the call site, and the line is a contract with the pager.
Audit Logging
This article explains audit logging as a tamper-resistant record of who did what and when, written in the same transaction as the state change. It argues that append-only alone is not tamper-evidence, and the same-transaction invariant is what makes a trail defensible.
Monitoring and Metrics Design
This article explains monitoring as deciding in advance what broken looks like, using counters, gauges, and percentiles. It argues that latency is percentiles, cardinality the hidden tax, and an SLO with an error budget turns an alert into a decision.
Health Checks
This article explains the two health probes, liveness and readiness, and why conflating them turns a dependency blip into a fleet restart. It argues that liveness must never depend on the outside world, or the probe becomes the amplifier it exists to prevent.
Retry Mechanisms and Backoff Strategies
This article explains retries as two decisions, which failures are safe to retry and how to spread them, via exponential backoff with jitter. It argues a deterministic delay keeps a herd synchronized, and an effect retried without an idempotency key is a double bill waiting.
Circuit Breaker Pattern
This article explains the circuit breaker as a three-state fail-fast gate for a failing dependency. It argues the value is in stopping the storm fast, that a retry sits inside the breaker, and that a fallback is a product choice, not an error.
Rate Limiting Algorithms
This article explains rate limiting as a design of burst shape and window, comparing token bucket, fixed, and sliding window. It argues the algorithm decides whether the boundary is a burst enabler, and the storage decides whether the limit is global or per instance.
Feature Flags
This article explains feature flags as a runtime gate that separates shipping from enabling a feature. It argues that a release flag should fail safe when its provider is down, and that a flag locked at 100% is dead code waiting to be deleted.
Designing for Observability — Putting It All Together
This article explains observability as the wiring that joins logs, metrics, traces, and health into one incident record. It argues that a metric with no clickable trace and log is not instrumented, and the missing layer is correlation, not another tool.
How to Approach Any LLD Case Study — The 45-Minute Framework
This article explains the five-phase framework for any LLD case study, from requirements through class design and the closing trade-offs. Its point of view is that the walkthrough is the part interviewers actually grade, and skipping it is how a perfectly drawn design still fails.
Design a Parking Lot
This article explains how to design a parking lot with a short entity list and two fully traced flows, entry and exit. Its point of view is that the deliverable is that minimal shape, with vehicle size as an enum and a single pricing seam.
Design an Elevator System
This article explains how to design an elevator system by separating the dumb machine from the controller that decides the next stop. Its point of view is that the two direction-keyed sorted sets are the algorithm, and scheduling in the elevator turns follow-ups into rewrites.
Design a Vending Machine
This article explains how to design a vending machine as a state machine, IDLE, HAS_MONEY, and DISPENSING, where every method is a guarded transition. Its point of view is that the state enum is the product, making the worst bug classes structurally impossible.
Design an ATM Machine
This article explains how to design an ATM around the ownership split where the terminal is dumb and the bank owns balances. Its point of view is that a local balance field fails on arrival, and the atomic account operation is the whole concurrency story.
Design a Chess Game
This article explains how to design a chess game by splitting piece movement patterns from the validator that applies blocking and king-safety rules. It argues the validator is only correct when it checks moves against a simulated board.
Design Tic-Tac-Toe
This article explains how to design tic-tac-toe as a two-class, ninety-line system where over-engineering is the actual failure mode. Its point of view is that declining to use any design pattern is the strongest answer in the interview, because nothing in the game varies.
Design Snake and Ladder
This article explains how to design snake and ladder by modeling the board as a graph of jumps rather than linear grid. Its point of view is that the graph model is correct, not a refinement, and it turns the minimum-rolls follow-up into a BFS.
Design a Library Management System
This article explains how to design a library management system around the split between a title and its copies, with the loan as the transaction record. It argues the loan, not the book, is the heart of the system.
Design a Logging Framework
This article explains how to design a logging framework around a producer-consumer queue where one writer thread drains immutable records. Its point of view is that the level check must happen before formatting, or the hot path pays for work it never uses.
Design an Inventory Management System
This article explains how to design an inventory system around the ledger as the source of truth and stock position as the derived count. Its point of view is that stock is a result, not ground truth, and the atomic check-and-apply on release prevents overselling.
Design a Car Rental System
This article explains how to design a car rental system around interval-based availability, where a vehicle's calendar decides whether a date range is free. It argues the boolean availability flag is the wrong model for anything rented over time.
Design a Hotel Booking System
This article explains how to design a hotel booking system around a count-per-night ledger, since rooms are interchangeable within a type. It argues there is deliberately no Room class, and the whole-stay commit is what makes partial bookings impossible.
Design a URL Shortener
This article explains how to design a URL shortener around the key-to-URL mapping and the key generation strategy every decision hangs off. Its point of view is that the read path is the business, and a boring cache-friendly lookup beats cleverness in the key generator.
Design Splitwise
This article explains how to design Splitwise around the expense record and the strategies that enforce the sum-to-total invariant. Its point of view is that the zero-sum check proves correctness, and the greedy settlement wins by being simple and honest about not being minimal.
Advanced LLD — What Changes at the Senior Level
This article explains what changes when you interview at the senior level: the case study is usually the same, but the bar is justification, not classes or patterns. It argues the strongest signal is naming the race condition before the interviewer asks.
Design a Movie Ticket Booking System — Handling Concurrency and Locking
This article explains how to design a movie ticket booking system around the seat as the unit of contention and the hold window that makes checkouts fair. Its point of view is that the locking strategy and its stated cost are the entire design.
Design an E-Commerce Shopping Cart and Order Flow
This article explains how to design an e-commerce flow around the split between the session-scoped cart and the order as a transaction. Its point of view is that merging them is how systems oversell, and the reserve-then-charge boundary plus idempotency key is the whole checkout.
Design a Notification System — Internal Class Orchestration
This article explains how to design a notification system as a pipeline where events become per-channel messages through a queue and a dispatcher. Its point of view is that channels must own their retry behavior, or a burst of events flattens the whole system.
Design a Rate Limiter
This article explains how to design a rate limiter by comparing the four counting algorithms and their memory and burst trade-offs. Its point of view is that naming sliding window and stopping is a failure, and the token bucket is the production answer.
Design a Job Scheduler
This article explains how to design a job scheduler around a priority heap of next run times and a lifecycle that recovers jobs from crashed workers. It argues the honest guarantee is at-least-once delivery with idempotent jobs, since exactly-once is a lie.
Design a Real-Time Chat System — WebSocket Handlers and Message Queues at the Class Level
This article explains how to design a real-time chat by splitting the per-instance socket registry from the message layer a broker bridges. Its point of view is that a global socket map fails behind every load balancer, and persisting before publishing enables offline delivery.
Design a Pub-Sub System Like Kafka — Internal Data Structures of the Broker
This article explains how to design a pub-sub broker as an append-only log split into partitions and stored in file-backed segments. Its point of view is that a broker is a log, not a queue, and the offset commit owns the at-least-once trade-off.
Design a Payment Processing System
This article explains how to design a payment system around the idempotency key claimed atomically before any provider call. Its point of view is that a timed-out payment must stay pending rather than fail, because that is the only way to avoid double charges.
Requirement Gathering Techniques for Interviews
This article explains how to gather requirements around four categories and the twenty-second scope restatement that follows. Its point of view is that the restatement is the cheapest insurance, since a fix in minute five costs nothing and one in minute thirty costs the round.
Identifying Entities and Relationships Under Pressure
This article explains how to identify entities under pressure with four moves: dump every noun, filter by responsibility, name the relationships, and delete out loud. Its point of view is that the invisible nouns, the ticket, the loan, the ledger, carry the design.
Choosing Design Patterns in an Interview
This article explains how to choose design patterns in an interview by naming the variation before the pattern and keeping only what is load-bearing. Its point is that saying no pattern at all is often the strongest answer available.
Discussing Trade-Offs Confidently
This article explains how to discuss trade-offs with the three-part structure of position, cost, and alternative with a trigger condition. Its point of view is that in the trade-offs with no winner, holding your position without flinching is the skill being tested.
Common LLD Interview Mistakes
This article explains the failures that lose LLD interviews, from missing records and misordered checks to folding under a push. It argues that nearly all of them trace back to one thing: no self-review.
Mock LLD Interview Walkthrough — End to End
This article explains a full mock LLD interview on an elevator, minute by minute, from extraction to the two-elevator push. Its point of view is that the machine-brain split is what turns the interviewer's hardest follow-up into a one-line answer instead of a redraw.
What to Do After the Interview — Learning from Every Session
This article explains what to do after an interview, a loop of hot capture, cold review, and a three-change commit. Its point of view is that the interview is data, not a verdict, and reviewing the passes is where the cure for the failures hides.