Hey. Looking at the patterns for daml, many of the examples are what i would call “aggregated data” contracts: as actions in the ledger occur, the master-contract is updated with further info (such as adding members/participants, expenses, etc.
There is also the pattern shown with the role-contracts and separation of data across multiple contracts: such as members being individual contracts instead of aggregated into a single contract as a list of parties.
is there any “notable” performance or design considerations for choosing aggregated vs separated/individual contracts.
I see it as: the aggregated gives you less active contracts (so more you can prune) vs the active contracts become larger and larger over time and it grows.
That’s the gist of it, but you do need to also consider transactions: because we want atomic transaction, there can be contention on individual contracts.
The single big “registry” contract is a lot more convenient for operations like listing all the members, but in some cases - and that will really depend on your use-case - if many different parties try to change it at the same time, contention can become a problem and introduce a bottleneck on your overall system performance.
On the other hand, the more distributed approach where each members knows the groups they’re part of makes it harder to “query” for all members of a group, but should in most cases lead to less contention: changing a member would not conflict with changes to another member.
If you look for “aggregation” in this forum you’ll find some deeper discussions of the tradeoffs involved.
@Gary_Verhaegen is a specific thread you would recommend? I had done a search for aggregation but did not see anything on the deeper trade-offs. This was the one that seems the more complex:
I thought I remembered some discussions involving at least @bernhard and @cocreature that discussed the different ways to navigate that tradeoff. Maybe they’ll know how to find those?
