In the world of event sourcing, it's not only about what happens it's also about how we talk about it. Language shapes how we think, how we design architectures, and ultimately the code we write. And sometimes, it's exactly that which sparks debate.

In recent weeks, a few GenesisDB users have asked us why our methods aren't simply called writeEvents() and readEvents(). Sounds reasonable, right? You write events, you read events. Done.

But that's exactly where the problem begins: those words don't describe what actually happens.

When you call writeEvents(), you aren't truly writing anything. Your application hands events to the event store, but whether they are actually persisted is decided by the engine. A precondition might fail. The stream might be locked. Maybe nothing gets stored at all.

The same applies to reading: readEvents() implies that there is something to read. But what if the subject doesn't exist? Then you read nothing.

The word "commit," on the other hand, reflects what truly happens. A commit is a deliberate attempt to persist a set of events with the possibility that this attempt might fail.

That's why we use commitEvents() and streamEvents(). We commit events the database does the writing.

Good language in APIs is no accident. It's precision in wording that mirrors the actual process. Because in the end, code is not just a set of instructions for machines. It's a conversation with other developers and with the future.

Beyond the Paradigm

There's another aspect of this discussion that is rarely addressed: some preach certain paradigms almost ritualistically. They insist that specific terms "must be named this way" because the community does it like that or because a textbook says so.

But this often overlooks something essential: language in APIs is not dogma it's a tool. A term isn't good because it's widely used; it's good when it accurately reflects what's happening.

Especially in event sourcing an approach that relies heavily on linguistic clarity, such as event types in the past tense this precision is crucial. A name like writeEvents() may sound familiar, but it doesn't reflect reality. A commit can fail; a read may return nothing at all.

And that's exactly why we chose commitEvents() and streamEvents() in GenesisDB.

Closing Thoughts

Language matters. Names matter. When we build tools that other developers will use, every word we choose becomes part of their mental model. The right word can clarify intent, prevent bugs, and make systems easier to reason about.

Words shape understanding, and understanding shapes code.