Jak zapisywać dane należące do użytkowników w innym mikroserwisie

Witam, mam pytanie, jak zapisywać dane należące do użytkowników w innym mikroserwisie czyli np. mam serwis auth gdzie jest przechowywany użytkownik i jak do niego przypisać dane z mikroserwisu np. wallet czy mam po prostu dodać do encji walet id_user, czy da się to jakoś "ładniej" zrobić

Jak zwykle, to zależy :)
W serwisie auth powinny być dane specyficzne dla "użytkownika".
Czyli np., username,password, id,

W serwisie z logiką biznesową powinna być encja użytkownika z jego danymi domeny, czyli np. imie, nazwisko, pesel, plus ten wallet np.
Po poprawnym zalogowaniu odszukujesz w bazie danych i przekierowujesz widok dla tego użytkownka

Tak w dużym skrócie

czyli użytkownicy powinni mieć to samo ID w różnych mikroserwisach

oczywiście, że tak - id to przecież identyfikator :D

czyli jakby w mikroserwisie np. tym z walletami powinien być użytkownik tylko z tymi potrzebnymi danymi i dopiero do tego robić np many to many z walletami

Nie myślałeś do tabeli wallet wrzucić kolumnę ownerId, które będzie właśnie userId z serwisu, który trzyma dane o userach, zamiast tworzyć tabele pośrednią? Zakładam, że ten serwis więcej info u użytkowniku nie potrzebuje a przynajmniej nie powinien :D

musiałbyś opowiedzieć na konkretny przykładzie i upewnić się, że w ogóle potrzebujesz zapisywać cudzą encję.
Można to robić np. przez eventy (obcy serwis propaguje message zapisałem nowy document i Twój serwis konsumuje to i zapisuje sobie) albo np. CQRS.

Nie wiem czy właścicielem encji Account powinien być MS Auth tylko np. MS Account/Client. Tak samo wallet niekoniecznie będzie pasować do MS Account/Client.

Myślę że można przyjąć zasadę kciuka że każdy "mikroserwis" powinien wiedzieć czy dany użytkownik ma prawo wykonać XYZ jeśli to dotyczy funkcjonalności za którą odpowiada. Oprócz tokena autoryzacyjnego są też idTokeny które mogą zawierać dodatkowe informacji bez konieczności pałowania przy każdym requeście serwisu User z pytaniem o uprawnienia i dodatkowe informacje. Tak jak kolega wyżej napisał taki serwis może publikować różnego rodzaju zdarzenia na które twój serwis może nasłuchiwać i dostosowywać konfigurację dla użytkownika - dodawać/odbierać uprawnienia do wykonania czegoś. Nawet nie chodzi o to że tak jest ładniej, bo masz sporo duplikacji, ale dzięki temu zmniejszasz coupling. Na początku to nie będzie pewnie problem, ale może nim się stać z czasem - zależnie od etapu projektu i skali musisz sam wywnioskować jakie podejście przyjąć, zrobić to gorzej ale szybko i tanio czy uwzględniając wzrost ruchu w przyszłości - który jednak jeśli nie nastąpi i np. projekt padnie albo nastąpi za 5 lat to zwrot z inwestycji będzie znikomy. Czyli tak jak kolega jeszcze napisał - to zależy.