5 ms·

The first rule of eventsourcing is don't eventsource EVERYTHING. Eventsourcing requires really, really detailed analysis of your boundaries (and no small bit o

The first rule of eventsourcing is don't eventsource EVERYTHING. Eventsourcing requires really, really detailed analysis of your boundaries (and no small bit of experimentation) to get right, even when you've done it before. It should really only be applied to the areas of your application that are going to see a real benefit from it. My proxy for measuring this is "how much money does this group of features make for me?" If the answer is some version of "none" or "none, but its a requirement to have it anyway" then I don't try to apply ES to that area of the application. I never use ES on user records anymore, for example. I'm sidestepping your actual question, but mostly because your use-case is something I consider to be a bit of a canard. To answer it though, as others noted, "it depends"—I model projections with actors, which means all events DO come through a single process handling events sequentially (and this is a very common way to do it.) But because I've got tons of these actors (one per stream that's actively running), there's no real bottleneck—this is also one way you guarantee ordering within a stream. Higher up in the stack, at the eventstore level, you'll probably have a pool of processes handling writes and routing events to the correct handlers/projections, but this is an implementation detail that can vary widely. The advice to not get bogged down in the details early on is good—the thing i see almost every developer new to ES do is get mired in the basic "how do i implement this" question, and that's really not what's going to kill your project. Not understanding nearly as much about your business and the software boundaries in your system is where most projects go wrong.

GordonS 9y ago
Do you build upon an event sourcing library, or have you written everything from scratch inhouse?
- karmajunkie 9y ago
  I've done both. My advice: use a well-maintained OSS library or server to handle the event store and subscriptions, because its easy to get bogged down in solving those problems yourself, and there's very little value in doing so.
  - GordonS 9y ago
    Can you recommend an OSS library you've had success with?
    - karmajunkie 9y ago
      My own is called Replay[1] but I wouldn't recommend using it for most people—I wrote it when I was first learning how to apply ES in Ruby back when the only material being written about it was for .Net. (I think I might have given the first-ever talk on ES at a RailsConf back in 2012.) Replay makes some assumptions I wouldn't make building something like that today, such as a very entity-focused perspective (e.g. in its original incarnation, all events were published from a projection by necessity), and it lacks some features I think a modern evented framework ought to have like projection snapshotting. I've got a lot of private changes to it to evolve it some, but you're better off going with something like Eventide[2] if you're working in Ruby today. I've also used some of Ben Smith's libraries in Elixir[3]. If you're in .Net, the Orleans framework has some really interesting ideas going on, and in Javaland, Akka and friends are what I'd start looking at. [1] https://github.com/karmajunkie/replay https://github.com/karmajunkie/replay [2] https://github.com/eventide-project https://github.com/eventide-project [3] https://github.com/slashdotdash https://github.com/slashdotdash
Vinnl 9y ago
> The first rule of eventsourcing is don't eventsource EVERYTHING. I've heard this rule so often now, but never what exactly it is that you _can_ safely event source. I'm afraid it's something you can only get a feeling for by doing it a few times and making mistakes, but that way of learning is hard to justify in real projects.
- karmajunkie 9y ago
  > I've heard this rule so often now, but never what exactly it is that you _can_ safely event source. I'm afraid it's something you can only get a feeling for by doing it a few times and making mistakes, but that way of learning is hard to justify in real projects. see above: >> My proxy for measuring this is "how much money does this group of features make for me?" That said, i think you're also correct—there's a lot of trial and error in developing your instincts for this architecture. That's also true of monoliths, web MVC, or really any architectural style. Experience, as they say, is that thing you only get AFTER you needed it.

GordonS 9y ago

Do you build upon an event sourcing library, or have you written everything from scratch inhouse?

karmajunkie 9y ago
I've done both. My advice: use a well-maintained OSS library or server to handle the event store and subscriptions, because its easy to get bogged down in solving those problems yourself, and there's very little value in doing so.
- GordonS 9y ago
  Can you recommend an OSS library you've had success with?
  - karmajunkie 9y ago
    My own is called Replay[1] but I wouldn't recommend using it for most people—I wrote it when I was first learning how to apply ES in Ruby back when the only material being written about it was for .Net. (I think I might have given the first-ever talk on ES at a RailsConf back in 2012.) Replay makes some assumptions I wouldn't make building something like that today, such as a very entity-focused perspective (e.g. in its original incarnation, all events were published from a projection by necessity), and it lacks some features I think a modern evented framework ought to have like projection snapshotting. I've got a lot of private changes to it to evolve it some, but you're better off going with something like Eventide[2] if you're working in Ruby today. I've also used some of Ben Smith's libraries in Elixir[3]. If you're in .Net, the Orleans framework has some really interesting ideas going on, and in Javaland, Akka and friends are what I'd start looking at. [1] https://github.com/karmajunkie/replay https://github.com/karmajunkie/replay [2] https://github.com/eventide-project https://github.com/eventide-project [3] https://github.com/slashdotdash https://github.com/slashdotdash

Vinnl 9y ago

> The first rule of eventsourcing is don't eventsource EVERYTHING. I've heard this rule so often now, but never what exactly it is that you _can_ safely event source. I'm afraid it's something you can only get a feeling for by doing it a few times and making mistakes, but that way of learning is hard to justify in real projects.

karmajunkie 9y ago
> I've heard this rule so often now, but never what exactly it is that you _can_ safely event source. I'm afraid it's something you can only get a feeling for by doing it a few times and making mistakes, but that way of learning is hard to justify in real projects. see above: >> My proxy for measuring this is "how much money does this group of features make for me?" That said, i think you're also correct—there's a lot of trial and error in developing your instincts for this architecture. That's also true of monoliths, web MVC, or really any architectural style. Experience, as they say, is that thing you only get AFTER you needed it.