Hacker News Reader

Comment by arkh | Hacker News Reader

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)?

View on HN

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.

This sounds like working around event sourcing - what value does event sourcing add here, vs simply not using it at all for user accounts?

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.

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.

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).

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.

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.

Reply on news.ycombinator.com