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

    Concurrency Design Best Practices

    Learning Objectives#

    • Name the handful of habits that keep a multithreaded service steady under load.
    • Choose the smallest correct concurrency tool instead of the biggest lock.
    • Recognize when a shared design is the problem and remove the sharing instead of patching it.

    Introduction#

    This chapter handed you threads, pools, locks, collections, and futures. The practices in this last article are the judgment that decides which of them to reach for, and in what order. Most concurrency bugs come not from a missing tool but from choosing the wrong level of the stack: a big lock where a collection would do, a shared mutable field where a copy would do, a hand-built wait where a queue would do. The best design is the one where the concurrency is a decision you made, not a consequence you met.

    Problem Statement#

    A service gets slower and slower under load, and the team finds a pool stuck, a cache that misses constantly, and a synchronized block that covers a network call. None of it is wrong in a single method; all of it is a pile of locks and waiting that should not exist. The failure is systemic: too much sharing, too-wide locking, and no single owner for the concurrency decisions. Fixing it means rethinking the design with the tools ordered by cost.

    Core Concept#

    The practices, in the order a designer should apply them.

    Prefer no sharing. The cheapest concurrency is the one that is not there. Copy the data, keep the state in one thread, or make the value immutable, and the locks vanish. The hardest problems are designed in when a mutable object is passed between threads for no reason.

    Choose the narrowest tool. An atomic field for a counter, a concurrent map for a shared cache, a pool for a workload, and a lock only when the collection cannot express the rule. Most code that reaches for synchronized or a ReentrantLock is guarding a check-then-act that a compute or an atomic already folds.

    Keep critical sections short. If a lock is needed, hold it for the fewest instructions, and never across an I/O call. A lock held through a network read makes every other thread wait on the network, the classic hidden serialization.

    Lock in a consistent order. With two or more locks, order them so a cycle cannot form. The deadlock chapter's fix lives here.

    Use the executor, not a thread. Ask a pool for work instead of building a Thread. The executor brings the bound, the queue, and the shutdown, for free.

    Time the waits. Every blocking call gets a timeout and a failure path. A future without a timeout, a lock without a tryLock, and a wait without a whenComplete each hang on the same spot: a condition that never arrives.

    Name the strategy at the boundary. A class shared across threads states whether it is immutable, confined, or guarded, so the next maintainer knows what holds.

    ExecutorService pool = newFixedThreadPool(4);   // bound the workers
pool.submit(() -> cache.computeIfAbsent(key, load()));  // narrow tool
future.get(2, TimeUnit.SECONDS);                // time the wait

    Real Production Usage#

    The companies that run large concurrent services converged on the same playbook: isolate state by request, share only through concurrent collections and message queues, bound every pool, and never let one slow dependency block the whole worker set. The honest note is that the playbook is not exotic. It is these practices applied steadily. When a production issue is a thread dump of a blocked pool, the fix is rarely a new concurrency primitive; it is one of these habits restored, a copy that removes the sharing or a timeout that lets a stalled call fail.

    Common Mistakes#

    1. Sharing mutable state by default. Passing a live object to a pool and adding locks later instead of passing a copy now.
    2. A coarse lock over a fine problem. Wrapping a whole map in synchronized where a concurrent map reads in parallel.
    3. A lock across I/O. Every thread waits on one network call, a serialization hidden behind a method name.
    4. A thread per task. No pool, no bound, and a spike of work becomes a spike of threads.
    5. An untimed wait. A blocking call with no timeout that holds a request forever.

    Interview Perspective#

    The design questions are "how would you fix a slow pool" and "what makes your system safe under load." The strong answer orders the tools: no sharing first, then the narrowest concurrent type, then a lock only when needed, then a timeout. Follow-up: "the lock and the network call" and "why an atomic over a synchronized." The answer to close on: the goal is to remove the sharing or the wait, and a lock is the last resort, not the first line.

    Knowledge Check#

    • What is cheaper than any lock, and what design move achieves it?
    • Why should a lock never be held across a network call?
    • Name the three knobs a blocking wait should carry in a production design.

    Key Takeaways#

    • No sharing beats good sharing; copy, confine, or make the value immutable.
    • Reach for the narrowest tool and hold a lock for the shortest section.
    • Bound every pool, order every lock, and time every wait.

    What's Next#

    The tools of this chapter are all about threads that run side by side and share. The next chapter is event-driven design, which changes the material: instead of threads blocking and coordinating on shared state, an event loop reacts to messages with no threads to lock or pool, and the coordination moves into the ordering of events. The questions become what to emit, when, and how the consumers keep up, a different shape from the lock and the pool.

    Want to Master Spring Boot and Land Your Dream Job?

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

    Learn more

    Last updated on Aug 19, 2026

    Was it helpful?

    Subscribe to our newsletter

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

    Previous
    Designing Thread-Safe Classes
    Next
    Introduction to Event-Driven Architecture