Recommended design pattern of fish


In case of creating a fish to contain the state of an object with many components, e.g., a machine, would you recommend to store all of its attributes in one fish type (eg. the machineState also has a doorState inside it), or separate fish to contain the component’s state (eg. while the general state of the machine is stored in machineFish, state of the machine’s door is contained in a separate doorFish)?
Is there any particular advantage/disadvantage of each patterns?

Thank you!

Hi Dipta,

we’re leaning towards smaller fishes in general, assuming that we can obtain auxiliary or summary information on demand, for example using AQL queries. Currently, AQL is probably not yet powerful enough to express everything you want, which means that e.g. not the whole aggregation can be moved from Fish to query, but some parts may stay in Typescript (meaning you FILTER the events in Actyx and consume them with the “reducer” pattern in Typescript).

One data point I can mention is that our own first apps contain a ProcessExecutionFish that tracks everything that happens to a production order on the shop floor. For a rewrite we’d definitely split this up into per-activity fishes (i.e. per production step) and remove all the statistics aggregation to keep it lean and clean (especially code bloat is a problem when trying to understand the interplay between fishes, so concentrate on the important state machine).

Now regarding your specific case I’d need more information for a good answer, but here’s how I’d go about deciding it:

  • within one Pond there should not be more than a couple hundred fishes actively used at any given time — there is a per-fish overhead, so splitting them up into too small pieces is not beneficial
  • if there are some state pieces that need to be kept in sync, update them from the very same event; the decision to emit this event needs to be done in a context that has the needed information, so some parts naturally “stick together” in the same Fish
  • otherwise, Fishes make great Local Twins for physical objects, in particular sensors and actuators; if the door can act independently of other things, then I’d start with a DoorFish until I see that that can’t work for one of the above reasons

Does this help? Let me know if you encounter scenarios that don’t fit into this thinking, I’m always curious to learn more!



Hi Roland,

thank you! In the beginning I tried to put many attributes in a single Fish but then it got complex pretty quickly. Especially I realized that a single fish consumes events from different “domains” (eg. related to door opening and to machining status), which are quite unrelated. So recently I tried to separate those things into different fishes, and your explanation totally makes sense and fits into the scenario I am currently working.


1 Like