Not sure if use case suits and specifically event sourcing

[Neil Hosey]

Hi,

I have an app that records event from a tracked vehicle.  

These events come in at regular intervals, and need to be stored for atleast 6 months.  There will be multiple listeners/projects of this data into various denormalised views, push notifications services and sending to external systems.

I'm wondering whether event sourcing is actually the wrong approach here?

From some of the talks I've listened to where Greg talks about thousands of events, I'm wondering whether having millions of events spread over several years for the same aggregate will just cause me performance issues over the life time of the product.

I am considering using EventStore for the actual event store, but my worry is the sheer number of events per aggregate.  

I am aware of the benefits of snapshotting here, but i was just wondering if there was an alternative or hybrid approach anyone has used for a similar system?

Thanks

Neil

[Greg Young]

"From some of the talks I've listened to where Greg talks about
thousands of events, I'm wondering whether having millions of events
spread over several years for the same aggregate will just cause me
performance issues over the life time of the product."

Most of your measurements (eg sensor readings) are not needed in most
cases I have seen to "rebuild the aggregate". In similar systems they
have put these measurements in another stream which was fine

> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dddcqrs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Studying for the Turing test

[Neil Hosey]

Ah ok, so by having 2 streams, would they both be then available to the same view model if i wished to view an aggregation of the 2 streams?

I'm wondering could I just use a single stream, and use projections to grab certain event types, or do you think this could lead to performance issues with eventstore?

Thanks for the reply btw!

[Greg Young]

You can always reindex etc but each reindex has a cost. What would be
the benefit of a single stream?

[Neil Hosey]

The reason being i am not sure if i can feed 2 streams into the same view model on the read side.  I havent done this yet.

I am also unsure how reindexing will help?  Can projections be used to read the events from the 2 streams?

[Greg Young]

Sure look at by category ...

[@yreynhout]

What of the vehicle exactly are you tracking? Depending on the answer you might be able to partition data into various streams with the TrackedVehicleId just being another piece of information on each event. And indeed, as Greg alludes to, what's the aggregate here, if any?

[Neil Hosey]

Thanks guys, both replies pointed me towards what i was looking for.  

[Aryeh]

Hi Neil,

>>> I'm wondering whether event sourcing is actually the wrong approach here?

What benefit of Event Sourcing do you use to justify its use?

For example, do you need to apply different algorithms or scenarios to a point in the past?  If I wanted to do something like apply different technical trading strategies to past prices that might be a justification.

I've been involved in the architecture of large event-based systems involved in the physical security (and access control) of large, banks, utilities etc.  The systems used for example by RBS, Banco Santander, ANZ or HSBC across thousands of distributed branches and facilities.  Imagine the volume of events for everything, from a hard kick to an ATM, to a teller's hold-up alarm. Event sourcing isn't used.

It would be great to hear why you consider(ed) adopting it, and what do you consider the architectural alternatives to be?  Would be really interesting to have a discussion about them.

Best regards, Aryeh

[Ben Kloosterman]

I've been involved in the architecture of large event-based systems involved in the physical security (and access control) of large, banks, utilities etc.  The systems used for example by RBS, Banco Santander, ANZ or HSBC across thousands of distributed branches and facilities.  Imagine the volume of events for everything, from a hard kick to an ATM, to a teller's hold-up alarm. Event sourcing isn't used.

Not Event sourcing for everything  but the transactions events ARE stored as events and aggregated and very similar to event sourcing ( im not sure if there is a difference)  . They are aggregated in statements over a period and then a balance rolled over ( in a single threaded batch where the whole DB is offline ) .

Ben

[Aryeh]

Hi Ben,

>>> "aggregated in statements over a period and then a balance rolled over"

I'm not sure if your reply was for another question?

Best regards, Aryeh