# Help with designing persistent actor hierarchy

**URL:** <https://discuss.akka.io/t/help-with-designing-persistent-actor-hierarchy/7144>\
**Category:** Akka Libraries\
**Created:** [September 8, 2020, 9:52am UTC](https://discuss.akka.io/t/help-with-designing-persistent-actor-hierarchy/7144 "2020-09-08T09:52:04Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Olafur](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.akka.io/olafur/32/1965_2.png) [@Olafur](https://discuss.akka.io/u/Olafur)\
**Post date:** [September 8, 2020, 9:52am UTC](https://discuss.akka.io/t/help-with-designing-persistent-actor-hierarchy/7144/1 "2020-09-08T09:52:04Z")

</div>

Hi guys

I’ve got a persistent actor model that is modelling an aggregate root. The event journal for this model is getting quite large (often over 10k events per actor) which can result in quite slow recovery times. As I understand it there are two ways to solve this: Snapshotting or splitting into more actors.

I’m a little bit afraid of snapshotting since the domain model is not serializable, so I’m afraid of possible data loss converting to and from a serializable model. Hence I’m looking at the possibility of splitting up into different actors.

For context, the shape of my domain model is something like this:

```auto
case class Foo {
 // lots of properties
 bar: List[Bar]
}

```

so my idea is to create separate persistent actors for each `bar` in the list. This list can contain from 1 to 2000 entities.

**Constraints and complexities**

The top level `Foo` actor will handle some commands that change the state of multiple `bar` entities. Since these are now split into different actors I’m afraid of message delivery guarantees in that scenario, i.e some `bar` actors might not receive a command. One possible strategy would be to contain that state in the `Foo` actor, i.e. no commands would need to be routed to be multiple `bar` entities, instead i’d contain that state in the `Foo` actor. I don’t really like that strategy since the state in question is inherently a part of the `bar` model.

So I guess my question is given this domain and constraints, would you go with snapshotting or splitting into different persistent actors, and if so, is it possible to guarantee deliveries from `Foo` to `bar`?