> Wouldn't it be easier to set a Cassandra TTL on the aggregates? That would allow them to automatically expire, rather than rely on finding
> an expired aggregate and then deleting it.

Because the aggregated entities need to be deleted at the same time, but they all get persisted at different times. TTLs expire "under the radar", so it helps to know when an aggregate was active then expired, because it helps us determine if we have AggregatedEntities that need to be deleted. If we didn't do that, we would have to read all the potentially expired aggregate entities before we can determine if we need to delete them (i.e., because their associated status doesn't exist), which seems excessive when we can just delete before having to look at them. Either that or always do a delete for all non-active aggregated entities all the time, which may be better, but seems funny to always be sending deletes for things that may or may not exist.

> If this is the only place where expired aggregates are being deleted, doesn't that mean that you could potentially have a large list of them
> that will never be deleted and will always stick around in Cassandra, as we might never again see their aggregateKey?

Ah, yes they would stick around if the aggregate key is never hit again. We could use a TTL for this case, though I wouldn't recommend the TTL to control expiry. We could set a TTL equal to or larger than `aggregateMaxExpiry` on all aggregate status and aggregated entity columns.