4 ms·

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 databas

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.

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.