Все в кучу смешано, но попробую ответить. Вообще не понял, в чем суть данной инфраструктуры, ну да ладно.
Я так понял, у вас клиент-серверное взаимодействие реализовано посредством очередей поверх натса.
Не понятно, зачем у вас клиент хранит данные, хотя этим должен заниматься сервер. Возможно в этом есть некая подмена терминов.
Будем называть это так: есть первый сервис, подменяющий src_ip и dst_ip в пакете из очереди, и отправляющий в другую очередь.
Есть второй сервис, также подменяющий src_ip и dst_ip в пакете из очереди, но уже отправляющий их в сеть напрямую по завершению.
Есть задача в первом сервисе хранить некие персистентные данные.
Вот как бы я это сделал.
Все сервисы лучше делать стейтлесс, чтобы можно было запускать сколько нужно реплик и не бояться, что данные где-то перепутаются. Можно, конечно, запускать одно и пытаться на нем все вытянуть и хранить данные в оперативе, но оперативка не дешевая, а с одним приложением можно упереться определенные ограничения на большой нагрузке.
Итак, я бы сделал несколько сервисов:
- сервис 1, принимающий пакеты из очереди 1, меняющий их, используя данные из бд (и записывая в бд), и пишущий результат в очередь 2
- сервис 2, читающий из очереди 2, меняющий данные, и отправляющий их в интернет (не понимаю, почему назвали его сервером, если там больше логики, то мб. имеет смысл писать в очередь 3, из которой будет читать третий сервис и только отправлять пакеты в интернет)
- опционально сервис 3, читающий из очереди 3 и отправляющий данные в интернет
А также инфраструктура:
- натс
- бд (что больше подходит/нравится, ну я бы взял редис или монгу как самые элементарные)
При этом можно масштабировать каждый сервис (запускать реплики), чтобы справляться с нагрузками. Это можно делать в кубере, а можно еще как-то, дело ваше.
Но вообще выглядит как сильно переусложненная фигня, это можно сделать в одном приложениями с тремя воркерпулами и двумя каналами.
