Lack of documentation, tutorials, videos or books - barrier to EventStore success?


I have now for quite some time tried to study all I can find on event sourcing and then decided to go for EventStore instead of trying to assemble a system with Kafka, or other some database and messaging system (like e.g. RabbitMQ) - and trying to do our own does not make sense, I think. But it seems like there is really no good introductions to EventStore anywhere. I’ve found 3 youtube videos by random people and then there is the documentation, which is rather scattered and no very systematic. And it does not really offer a way to learn using EventStore. I know there is a commercial version also, but this seems like a quite high entry barrier for anybody interested in using EventStore which I think in turn will affect the commercial viability of EventStore.

Maybe EventStore is easy to use, for people who already knows “everything”, but some of us don’t :slight_smile: and the documentation is simply to sparse to provide learning in my opinion.

Is there really no courses, books or tutorials for learning to use EventStore from Node JS and C#?

kind regards,


Thing I’d suggest to a new architect with an interest in ES would be to first read all they can find on

  • Event-Driven Architecture

  • Stream Processing

  • Complex Event Processing

Thanks - I have spent a lot of time on that - videos, blog posts, all sources I could find - and now just want to get going and find the EventStore documentation quite disappointing, which is a shame, since I really think the concept is very solid. But there is just too much guess work / friction to start using it, unless I’ve overlooked something

What things are you missing?

I’ll collect examples on what I’m missing as an Eventstore beginner and get back here. Thanks

The biggest issue I’m facing is the need for a “Common issues” guide. Things like increasing file handles on Linux so it doesn’t blow up when you hit a certain db size, tuning your heartbeat and gossip intervals depending on your environment. Suggestions for if you start to hit certain issues (like commit timeouts on projections).


I think that something along the lines of and docs linked from there should be in ES docs.

with VC to fund scaling features and good docs, ES would be on par with Confluent

Speaking of alternatives like Confluent, Jet seems to be building out their own open-source event sourcing engine as a replacement for EventStore to address some of their difficulties.

It doesn’t seems an EventStore “replacement”. They added Kafka as up-stream in front of EventStore showing how they replicate their solution across 2 datacenters. They are doing mappings and transformations between the Kafka consumers and the Eventstore down-streams and therefore personally I’m not sure that this is a good idea for the complexity of handling failures on separate systems. But still an interesting read.

Reading the title of this thread I wonder why this article as been brought in? The web is full of different ways to architect message driven solutions using raw stream processing or more structured DDD approaches. I know that it’s hard but Google seems to me the best source of information. I like to use EventStore as a flexible engine and build my car around it. They can provide some examples and give directions but the rest is our sweat :slight_smile:

You’re talking about their current solution, I’m talking about the next-gen event sourcing engine they are developing (that’s not in use yet).

geo-replication is a pretty easy feature to add (and its being added currently). Maybe send me an email offline and we can discuss how it will work. It will be AP not CP

A useful first step in documentation would be a glossary of the terms used in the Dashboard. The Dashboard is usually the first contact point after install;



Projection Core

Projections Master

Storage Chaser










Add a small (?) image near the term with a small popup that defines what it is would be great

I second the OP.

I find the documentation on very confusing.

The first thing you see when you get to the docs page is the in the navigation at the left side. This is quite okay. I click on “Getting Started” and read about how to start the server, http POST and event (why not use the .NET client?) and how to read events using HTTP (why not use the .NET client?).

I which there would be a slightly different structure as in “Setting up your Development Even Store” and “Storing and reading your first event” both via HTTP and the .NET / Java/ whatever clients.

However, the second article on the navigation side then is “Competing Consumers Introduction”. And in the second paragraph it says that the Competing COnsumers differ in usage from the Subscribe operation or from a CatchUp Subscription. And I am completely like “differ from WHAT”? And I’m searching for an explanation or an example for these two and can’t find that.

After quite some time I found out that the “Getting Started” series on the Documentation Home is NOT the “Getting Started” from the left side navigation, but links to different articles, and there might be an explanation.

So, in short, at least for me the bar to really start using Event Store is quite high.

And I am currently only using that for a pet project. But maybe some day I will end up with a customer that is in need for a solution where that might fit. And a low entry bar would make it easier for them to get started and maybe aquire one of the commercial packages.

I even opened an issue on how to solve the open files failure but I believe Greg doesn’t see it as an issue at all. I also suggested a line in the docs and the answer was “one is not enough, try 100+” so we are left with none.

End of rant.

This is not an eventstore issue this is basic linux administration, I mean I even knew it and am completely stupid at anything beyond being a desktop linux user in linux.…69i57j0l5.5102j0j7&sourceid=chrome&ie=UTF-8

This is a generic linux configuration problem not an EventStore issue. Under this logic we should also write documentation for “Cannot bind to address: address already in use”. These are OS level errors. Would you prefer us spend our time (currently doing) and making ES documentation better or documenting what should be obvious OS level errors (there are thousands).

Yeah, send me an invoice for wasting your time. You do not have to read this. And I can remove the issue, no problem.

The biggest issue I’m facing is the need for a “Common issues” guide. Things like increasing file handles on Linux so it doesn’t blow up when you hit a certain db size, tuning your heartbeat and gossip intervals depending on your environment. Suggestions for if you start to hit certain issues (like commit timeouts on projections).

If this is not something obviously relevant because there are numerous encounters of this particular issue in this group and in our production experience we had it twice, among with, surprise, tuning the heartbeat and gossip intervals.

These are exactly two main issues we ever had in production (among with stuck projections but this was recognised as a bug) and we are in production for one year and four months now, as your paying customer. Not “thousands” of mythical OS issues that never happened. Concrete, specific issues that almost anyone hit but not everyone reported.

I would recommend in general checking your number of open files and usage vs your ulimit and /etc configurations. We cannot do this for you as you likely have other things running on the same machine (like say an application server, tcp sockets cost as well against ulimits). We cannot automate this for you.

If you look closely the limit is on file descriptors. We cannot forecast the number of file descriptors used in your system. They are used for files, they are used for networking, they are used for talking to devices. If you do a “ls -l” which opens at least one file descriptor depending on the command we do not know this. We do not have this information. We then have multiple limits over which we have no control.

As a perfect example you could do a “ls -l”,a “vi”, or even a "telnet " which prevents ES from opening a new file.

Increasing the configuration should alleviate any issue.