CQRS Pattern — Separate Read/Write Models in Spring

CQRS separates the model used to write state from the model used to read state. The motivation is that writes need a rich domain model with business invariants and validation, while reads need fast, flat projections tailored to specific views — and a single model optimized for both typically does neither well.

In a Spring Boot application, lightweight CQRS means separate service classes. A command service annotated with @Transactional works with the full domain model — Order entity with business rules, state transitions, validation. A query service annotated with @Transactional(readOnly = true) works with Spring Data interface projections — flat DTOs that fetch only the columns needed for a specific view. The readOnly flag tells Hibernate to skip dirty checking entirely, which gives a measurable performance improvement.

The more advanced form uses separate databases for reads and writes. Commands write to a normalized relational database. Events derived from those writes populate a read-optimized store — Elasticsearch for search, Redis for dashboards, a denormalized read DB for fast queries. This enables independent scaling but introduces eventual consistency — the read model may briefly lag behind the write model.

Two things interviewers specifically test for: first, CQRS is not Event Sourcing. They're independent patterns that are often combined but neither requires the other. Second, most applications don't need full CQRS with separate databases. Lightweight CQRS — separate services, same database, read-only transactions — is the pragmatic starting point that gives you the separation benefits without the infrastructure overhead.