CQRS Explained
Most systems read and write one model — and that single model ends up bad at both jobs. CQRS splits them: commands mutate the write model, queries read a separate read model, and the two sync however the data allows. This video shows what each side optimizes for and where the split pays.
Topics covered:
- The unified model's problem: one shape for writes, reads, and reports
- Commands: mutations expressed as intents, not data edits
- Queries: read models shaped for screens, joins, and projections
- The sync path: same database, event stream, or read replica
- Why CQRS pairs with event sourcing: the write model as an event log
- Projections: building the read model from events instead of triggers
- The consistency trade: eventual consistency between models and its costs
- When CQRS is overkill: CRUD apps and single-model systems
Related articles
Testing Strategies for Architecture: Pyramid, Trophy, and Contract Tests
Architecture decides test cost — the test pyramid vs the testing trophy, where contract tests fit between services, and why dependency structure determines how fast your suite runs.
Microservices Are a Cost, Not a Benefit
Every microservice multiplies pipelines, on-call surfaces, and coordination edges. Here is the operational cost math, when a monolith beats it, and how the strangler fig splits one.
Monolith First: Why Simple Beats Distributed
Before microservices made sense for anyone, they were a cost center pretending to be scale. A review of when a monolith is the right architecture — and when the call for services is actually a cry for discipline.
More in Software Architecture
The Strangler Fig Pattern
How to replace a legacy system without a rewrite — routing by path, strangling features incrementally, and keeping both systems honest.
DetailsDomain-Driven Design Basics
The core of DDD without the ceremony — ubiquitous language, bounded contexts, aggregates, and where the model boundary actually goes.
DetailsService Mesh Explained
What a service mesh actually does — sidecars, mTLS, traffic routing, and observability — and the network plumbing it takes off your plate.
DetailsFeature Flags in Practice
How feature flags work end to end — evaluation at runtime, kill switches, and canary rollouts — plus the operational discipline they demand.
DetailsThe Saga Pattern Explained
How distributed transactions work without distributed locks — saga steps, compensating actions, and the orchestration vs. choreography split.
DetailsAPI Gateway Patterns
What an API gateway actually does — routing, auth, rate limiting, and aggregation — and which patterns matter for your traffic.
DetailsHexagonal Architecture, Visualized
Ports and adapters in one diagram — how hexagonal architecture keeps business logic independent of databases, HTTP, and everything external.
DetailsEvent-Driven Architecture Explained
How event-driven systems work — events, topics, and consumers — and what the broker actually guarantees in a distributed system.
DetailsMicroservices vs. Monolith
The honest engineering comparison — deployment boundaries, data ownership, failure domains, and the real costs of splitting a system.
DetailsDepth, delivered weekly
One technical dispatch a week — articles and episode notes before they go public.
One technical dispatch per week. No noise.