Just so we’re on the same page, are we talking about a Temporal Memory style where transformation logic changes dynamically in response to new input? (as an illustration, I’ll borrow @Paul_Lamb’s diagram rather than draw my own). It would be handy to know how your architecture differs in terms of processing distribution and state transfer.
The short answer is that you can always refactor and insert service mesh logic later, and there are implementations like linkerd-tcp that can somewhat squeeze in-between existing TCP applications. Without reigniting the functional vs imperative holy war, I would just make sure you’ve been a good dev and separated out the transport code into a single function that accepts your token data and takes care of the socket calls, this would of course make refactoring easier later.
If you’re planning to focus on transformation processing and having a simple, static topology doesn’t compromise the design then I’d say strike while the iron’s hot rather than spend the next two days reading kubernetes/linkerd doco. However, if routing logic and state synchronisation is (or becomes) a major factor then I think it’s worth pausing and looking at how this has been solved already.