with the interface decomposition, establish the common contexts that overlap between the methods and if you recognise they are independent then they can be made into their own, like for example if a set of methods mainly relate to filtering, then they are filtering methods, if a set of methods are about counting, they are counting methods, if they are iterators (or walkers) they are this type it can be good to make an interface for anything that could have an entirely differently constructed API behind it, thus necessitating a shim or adapter that translates from one API to another (and this is why interfaces are an indispensible construct that is neglected by all but Java programmers other than Go) and, regarding the last parts about the interface splitting there, i mentioned above from the first how to figure it out, it could be 2 or 3, just from what i saw, but i wasn't familiar enough with their semantics to catch that creating a neutral interface for the database makes a lot of sense too, because you have used redis there, which is fine, but by using an interface instead of directly coupling to the other API you retain the flexibility to use a more optimal store, or more distributed, or byzantine fault tolerant even, you can also then too use "gateways" that cache access to other data and so on and so on and i think i mentioned this, but making "iterator/walker function types" that the iterator calls with the data from the current node, you can simplify isolating your per-node scope but also enable concurrent safe access to a shared state, which is essential in order to parallelise the processing, again, you may not need it now but if your API calls methods that contain the node state data they can handle locking the data for teh case that concurrently that might be part of a pool of data objects, so not just for enabling synchronisation, but you can also enable bespoke memory and scheduling independant from the primary calculation work, in order to change the way the data flows through