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

    CQRS: Command Query Responsibility Segregation

    Learning Objectives#

    • Define the split CQRS names: a write model that changes state and a read model that answers queries.
    • Explain when the shape of the two should differ and why one object for both is a bias toward whichever side it favors.
    • State the storage options, the same store split into a read replica, distinct read stores, and when the extra is warranted.

    Introduction#

    CQRS is the short name for command query responsibility segregation: the code that writes state and the code that reads it stop being one class. It gets paired with event sourcing all the time, but it is its own idea and you can run it without a single event. The claim underneath is plain. A single Order object used to update stock, render a page, and feed a report assumes that reads and writes want the same shape, and that assumption is worth questioning.

    Problem Statement#

    One Order class is the object the service loads, the object the front end renders, and the object a reporting job scans. Three users with three demands. The write path wants invariants and a transactional guard. The read path wants no business logic and the cheapest page, ideally a flat view. The report wants high throughput across many rows. Every concern hits the same shape, so the model is a compromise that fits none of them, and a read that grows joins slows the same write that shares the object. The failure is one class being asked to be a command, a query, and a projection.

    Core Concept#

    CQRS splits the model in two. The write side speaks in commands, PlaceOrder, which carry the intent and land on an aggregate that enforces the rules and changes state. The read side speaks in queries, GetOrderView, and returns a projection shaped for a screen or a report. The two do not share a class and are not required to share a store.

    // the write model: a command describes an action, an aggregate holds the rules
public record ChargeCommand(String accountId, Money amount) {}

// the read model: a view shaped for a screen, with no behavior
public record AccountStatementView(String accountId, Money balance, List<ChargeView> rows) {}

    The names tell the point. ChargeCommand is an instruction carrying what it takes to act. AccountStatementView is a shape whose wording answers the UI. CQRS is the rule that these two never become a single Account that mutates while it renders.

    The payoff is in the design, not the JSON. Once the write and the read are two classes, each takes its own shape: the write model protects the invariant, and the read model is free to be a dumb join that serves the page. The read that used to slow the write because they shared a table now keeps its own projection, and the write transaction stays short.

    Real Production Usage#

    CQRS and event sourcing pair well, because the projection from the event log already provides a read shape and the aggregate gives a clean write. But CQRS alone appears in a simpler jacket: a read replica, the same database where reads go to a secondary and writes go to the primary. Reads scale by adding replicas, and the writes are never slowed by the read load. When the read and the write push in opposite directions, a duplicate read model is worth the price.

    The level of separation is a dial. Some systems split only the class and the transaction boundary; others split the schema and keep a read store that folds events. The dial turns up as read pressure climbs and drops back near zero when the application is a form that edits a couple of fields.

    Common Mistakes#

    1. Adding CQRS to a CRUD service that already fits. Four reads and two writes gain a projection, two stores, and a staleness window the single-form user never asked for. The machinery does not pay.
    2. Splitting names, not models. If the write and the read still share one class and you only rename the methods, you have CQRS without the separation. Behavior never a working, the model did.
    3. Letting the read mutate the write. A query that writes back to the write model grows a second authority, and you have the very same shape you removed.

    The telltale anti-pattern to watch for is an ORM entity passed up to the renderer and down to the writer at the same time. That is the shared shape returning, and the fix is the same line: a command into the aggregate and a separate projection to the query, with the view built by folding.

    Interview Perspective#

    The interviewer wants to hear that you know CQRS is a real separation, not a rename. Weak: "CQRS is separate read and write." Strong: "CQRS runs a command into the write side and a query into the read side, so the shape matches the job, the reads get a replica or a projection, and the write keeps its invariant." Follow-up: "does CQRS need event sourcing," and the strong answer: "the projection is a natural pair, but CQRS needs only a separate read, a replica works, so the two are close but independent."

    A second follow-up is "when do you reach for it," and the answer is when the read and the write genuinely differ in scale or shape, or when the read must not be coupled to the write's transaction.

    Knowledge Check#

    • A single object is loaded, changed, and returned by the same code path. Which two pressures fight on that object, and what does each side of CQRS give its own?
    • The read side can use a separate shape. Name the two storage arrangements that satisfy it.
    • Does CQRS require event sourcing, and what is the minimal version? Explain why the two are often paired but independent.

    Key Takeaways#

    • The write model is a command plus an aggregate; the read model is a view plus a projection, and they are two shapes.
    • CQRS earns its keep when the read pressure outweighs the write; it is not a default, and the CRUD that fits one shape is fine as it is.
    • A separate read can reference a replica or a fold, which is what lets the read scale apart from the write.

    What's Next#

    The split models of the chapter are in place, and every one of them is a place to fail quietly. The next article gathers those failure habits, the common pitfalls of event-driven systems, and reads back through the chapter to name the mistakes that make each technique fail in a running system.

    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
    Event Sourcing — Concepts and When to Use It
    Next
    Common Pitfalls in Event-Driven Systems