This Isn't Event Sourcing
•February 21, 2026
0
Why It Matters
Choosing event sourcing only when the domain generates meaningful events prevents unnecessary complexity and aligns technology spend with business value.
Key Takeaways
- •Only state changes, not CRUD, qualify as true events.
- •Event sourcing adds complexity; use it where domain naturally emits events.
- •Each new component raises operational, maintenance, and cognitive costs.
- •Architecture decisions should align with business goals, not just technology.
- •Understanding trade‑offs is essential before adopting event‑driven designs.
Summary
The video clarifies that not every state change qualifies as an event; creating a shipment is merely CRUD, while actions like order dispatched, shipment loaded, arrived, or delivered are true events. It argues that event sourcing can become over‑engineering if applied indiscriminately, emphasizing that the decision to adopt it must stem from domain characteristics rather than habit.
The speaker highlights trade‑offs: each added component increases operational complexity, engineering effort, maintenance burden, infrastructure cost, and cognitive load. Without a solid grasp of these trade‑offs, teams cannot judge whether the benefits of an event‑driven architecture outweigh its overhead.
A key quote underscores the business nature of architectural choices: “Architecture is not a technical decision. It’s a business decision.” The discussion references a prior thread, reinforcing that thoughtful evaluation, not blind adoption, is essential.
For practitioners, the takeaway is clear: adopt event sourcing only where the domain naturally emits meaningful events, thereby avoiding unnecessary complexity and aligning technology investments with strategic business outcomes.
Original Description
CQRS isn’t “two databases,” and read replicas aren’t CQRS. CQRS, the Outbox pattern, and Event Sourcing are often called “overengineering,” and I push back with clear definitions and real-world failure modes. We’ll break down why Outbox exists (the dual-write problem), how CQRS is simply separating command and query code paths (even with the same database), and why logging events to ClickHouse/Redshift is analytics, not Event Sourcing. If you’ve heard “outbox is only for finance” or “replicas are enough so CQRS is useless,” this is the nuance people miss.
🔗 Kurrent (formely EventStoreDB)
💥 Join this channel to get access to a private Discord Server and any source code in my videos.
🔥 Join via Patreon
✔️ Join via YouTube
📝 Blog: https://codeopinion.com
👋 Twitter: https://twitter.com/codeopinion
✨ LinkedIn: https://www.linkedin.com/in/dcomartin/
📧 Weekly Updates: https://mailchi.mp/63c7a0b3ff38/codeopinion
0
Comments
Want to join the conversation?
Loading comments...