Timeline for How to model a shopping scenario using event sourcing
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 11, 2017 at 13:06 | comment | added | Fyodor Soikin | Second, the specific strategy of how to replay the events really depends on your application, I can't give you an advice of that level of specificity. However, keeping the whole event steam in memory is probably not a good idea: it simply won't fit, unless your application is really small and nobody uses it. | |
| Jul 11, 2017 at 13:03 | comment | added | Fyodor Soikin | First, yes, there should be a "product added" event. There should never be any data that your application somehow "knows about", but isn't derivable from the event stream. Event stream must be the principal storage. No other sources of truth. | |
| Jul 11, 2017 at 12:57 | comment | added | codependent | I can't see how to validate the state of the stock against the event store. First, should there be a ProductAdded event per product in the store? Second, how can I process the state of the store to find the real product availability using Kafka? Should this state be kept in memory of the services? Should I reprocess completely every time you want to check it? Wow that's many doubts :-) | |
| Jul 11, 2017 at 12:47 | history | answered | Fyodor Soikin | CC BY-SA 3.0 |