# Time-series data with Akka Actors

**URL:** <https://discuss.akka.io/t/time-series-data-with-akka-actors/5792>\
**Category:** Persistence / Event Sourcing\
**Created:** [January 25, 2020, 6:37am UTC](https://discuss.akka.io/t/time-series-data-with-akka-actors/5792 "2020-01-25T06:37:09Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![ignatius](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.akka.io/ignatius/32/1787_2.png) [@ignatius](https://discuss.akka.io/u/ignatius)\
**Post date:** [January 25, 2020, 6:37am UTC](https://discuss.akka.io/t/time-series-data-with-akka-actors/5792/1 "2020-01-25T06:37:09Z")

</div>

I am wondering, what is a good approach to handle time-series data in an Akka Actor application?

My current approach does not involve actors. Time-series entries/values are represented as simple numeric or case-class instances. Those instances are both written, or read from the database (Cassandra) and then processed further using Akka Streams.

I am wondering if there is a more Akka dogmatic way to handle time-series data (that makes sense). For example, each time-series belongs, in DDD terms, to an `aggregate`. This `aggregate` entity could be represented as an Actor. For example, it could have the current time-series data as state, then to be queried by consumers instead of the database, and passivated while not in use.

I don’t think the latter approach is sensible, because you’d have to replay all time-series data to recreate the actor (after passivation) even if you only need a subset and, as far as I know, you’d have to give up on low-level primitives in the database, and use the more space- and CPU intensive serialized versions of events when reading from the database. As far as I understand is, this is one of the reasons why CQRS is used in the the first place.

Maybe we don’t have to use Actors for everything, and I don’t see much wrong with the database approach. Still, in hope that I might learn something new, I’m curious if I could improve my approach above reading and writing everything directly to the database. Maybe there is a nice pattern that could improve this kind of thing.