5 ms·

Thank you for this. I've been warning people off Event Sourcing for a while now. The architecture is the most convoluted, pretentious, redundant and downright s

• AndrewKemendo 7y ago
  I think you're doing it wrong. It shouldn't be any more complicated than writing events as a producer to a Kafka topic. Gets more complicated when you add in distributed computing, redundancy etc... However those things are always complicated
  • Yuioup 7y ago
    I got handed down an Event Sourcing project because the client left the original developer because he kept getting burn-outs. I can't shake off the project because it keeps getting stuck to the bottom of my shoe.
  • arkh 7y ago
    Simple problem: checking users have the rights to do something before you let them. Do you reconstruct the user account every time you want to check their rights (so, for every action they do)?
    • Autowired 7y ago
      No, you should not compute the state you need from the event log on every request, this would be absurd. Your authorization service can maintain its own database (a "view" of the current state), or even an in-memory representation computed at startup, and update it whenever a new event pops up. Alternatively, if you are using Kafka, you can use stuff like KTables to do this.
      • GordonS 7y ago
        This sounds like working around event sourcing - what value does event sourcing add here, vs simply not using it at all for user accounts?
        • m45t3r 7y ago
          For this specific case, nothing, however let's say you need to know when the user got a specific scope and from who. You probably can answer this question in SQL if you prepared your database to do it (i.e: a changeset table), however in an event sourcing architecture you would gain this information for free. However, just because you're using event sourcing doesn't mean you don't have a database with the current state of your entities.
          • dgregd 7y ago
            In Ruby on Rails one can add just one line of code to achieve the same result. class User < ActiveRecord::Base has_paper_trail end That solution is good enough for most use cases and doesn't require highly skilled architects and developers to implement Event Sourcing properly.
        • fennecfoxen 7y ago
          That's command-query responsibility segregation. The command stream gives you the nice log of everything that happened, while the read database is easy to query (and to reprogram if necessary).
          • GordonS 7y ago
            Isn't that confusing two different things, CQRS and ES? I use CQRS all the time, but have never built a system using Event Sourcing. Regarding logs, "traditionally", I'd use an audit/change history table for objects that needed one.
        • Autowired 7y ago
          The siblings already said it, but event sourcing requires you (at least for practical purposes) to segregate the read model from the write model using "projections". The good thing is that, whenever you create a new service, you can derive the projections that your service will need from the same source of truth. In this way, you create coupling on the data, but not on the concrete service that owns it. This is not very different from what a relational database does with redo logs. In fact, in a way, using event sourcing resembles composing a system from the fundamental building blocks of a traditional DBMS, in a distributed way.
• inopinatus 7y ago
  Some of worlds most useful and powerful data structures are the projection of an event log. The tables of a RDBMS, the balanced writes of a SSD, and even the classic: double-entry book-keeping. Even the data stream of a TCP connection is a projection of events, which is why (and how) we can reconstruct them by replaying captured segments. So just because there are some lousy executions of a general architecture, doesn’t mean we should recoil from the basic idea. My takeaway is that successful event-sourced structures are crafted for the domain they represent. I’ve developed a couple for my own work, for very specific aspects of an application, and they work well in context. If your experience has been that a general-purpose ES framework leads to shitty, hard-to-maintain apps, I’d say that’s evidence for the corollary.
  • nvarsj 7y ago
    Just because a tool is powerful doesn’t mean it’s appropriate. There’s a reason most people should just use a DB and not a raw event log. The issue I have with ES proponents is they seem to all pretend there is no additional complexity that comes with it. I think ES is useful but not always and requires weighing the costs and benefits, and we need to be honest about it.
  • legulere 7y ago
    You could say the same about e.g. lock free algorithms. If you work on them you are usually just playing with some cool technology instead of solving the business requirements.
• ekvilibrist 7y ago
  I've only suggested event sourcing once, and that was for keeping physical warehouse inventory synced with orders. I.e. instead of having like a database table with a "available product count", we made a view that calculated "product stock minus pending orders" on the fly at any given timestamp. Very efficient, simple and easy to debug. But as a general system architectural pattern it does seem to create more issues than it solves. Just look at the MailService example in the article. Dude, just use a queue...
  • Mouse47 7y ago
    Good approach. Much of software engineering is applying principals like event sourcing judiciously. Why does the whole system need to be in one architecture?