Event Sourcing in Go: From Zero to Production

Sqlite can scale CQRS to 100000 events per second on a relatively small VPS. That's 10x what the author achieves with postgres.

You can scale them independently in that you can control the rate at which your views are read and the batch size of your updates.

The whole big win wirh CQRS is it allows for very efficient batching.

I think having constantly changing product requirements would certainly make it difficult, but that makes all development more difficult.

In fact, I think most complexity I create or encounter is in response to trying to future-proof stuff I know will change.

I'm in healthcare. And it changes CONSTANTLY. Like, enormous, foundation changes yearly. But that doesn't mean there aren't portions of that domain that could benefit from event sourcing (and have long, established patterns like ADT feeds for instance).

One warning I often see supplied with event sourcing is not to base your entire system around it. Just the parts that make sense.

Blood pressure spiking, high temperature, weight loss, etc are all established concepts that could benefit from event sourcing. But that doesn't mean healthcare doesn't change or that it is a static field per se. There are certainly parts of my system that are CRUD and introducing event-sourcing would just make things complicated (like maintaining a list of pharmacies).

I think what's happening is that a lot of hype around the tech + people not understanding when to apply it is responsbile for what we're seeing, not that it's a bad pattern.

I don't think this design in the article works in practice.

A single `events` table falls apart as the system grows, and untyped JSONB data in `event_data` column just moves the mess into code. Event payloads drift, handlers fill with branching logic, and replaying or migrating old events becomes slow and risky. The pattern promises clarity but eventually turns into a pile of conditionals trying to decode years of inconsistent data.

A simpler and more resilient approach is using the database features already built for this. Stored procedures can record both business data and audit records in a controlled way. CDC provides a clean stream for the tables that actually need downstream consumers. And even carefully designed triggers give you consistent invariants and auditability without maintaining a separate projection system that can lag or break.

Event sourcing works when the domain truly centers on events, but for most systems these database driven tools stay cleaner, cheaper, and far more predictable over time.

Stuffing data into JSONB columns always makes me feel uncomfortable. Not necessarily for performance/efficiency reasons. You also loose the strong schema that SQL gives you, you don't get to use constraints. You might as well use Mongo, no?

How can you be sure that the data stuffed into JSONB fits a particular schema, and that future changes are backwards compatible with rows added long ago?

> it expects a level of correct-design-up-front which isn't realistic for most teams

It requires a business that is willing to pay the maintenance cost of event sourcing in order to get capabilities needed capabilities (like an audit trail or replayability).