Questo sembra una scelta sbagliata come presentata, ma ci sono anche diversi tipi di dipendenze da considerare che hanno una diversa soluzione "giusta". Detto questo, non posso pensare a un singolo caso in cui una delle soluzioni proposte sia quella giusta.
Mentre lo scrivevi, il Service B non può fornire il suo output senza una risposta dal Servizio A. Questa è una bandiera rossa per me, e mi dice che probabilmente non dovrebbero essere microservizi separati. Significa anche che nell'architettura corrente, il modo solo di gestirlo è che il Servizio B parli direttamente con A e fornisca una risposta composta al client attraverso il gateway API, ed in effetti esso è anche una bandiera rossa che probabilmente non dovrebbero essere due microservizi. Se ciò è vero, l'output di B non in realtà "dipende da" A.
Se quello che intendevi era che l'endpoint del servizio esposto dal gateway API è una composizione di informazioni dai Servizi A e B, allora questa è la tua risposta; ognuno è indipendente e viene composto dal Gateway.
Se quello che intendevi era che il servizio A ha bisogno di data per il servizio B (solo dati, non logica aziendale), allora un'altra risposta potrebbe essere un archivio dati condiviso (un database tradizionale o una coda di messaggi) o qualsiasi altra cosa a cui entrambi i microservizi parlano.
C'è una discussione abbastanza buona sulle opzioni e sul "perché" della composizione del servizio all'indirizzo Auth0 che potresti trovare illuminante, e potrebbe anche aiutarci a creare risposte migliori per te, se fornisci il tuo caso aziendale specifico piuttosto che utilizzare generici come "Servizio A" e "Servizio" B".
Dopo l'aggiornamento delle domande
Nel caso di utilizzo aggiornato, ristrutturerei le opzioni in base a quali usi altri di questi microservizi esistono. In nessun caso al momento posso pensare che il microservizio Selection debba chiamare direttamente il microservice di Placement.
Invece, dovrei comporre il lavoro nel gateway API come descritto, o consolidare i microservizi in un singolo componente.
Fornire un'API unificata e di livello superiore che gestisce più chiamate di servizio a monte è ben all'interno del loro ambito, imo. Il motivo principale per cui potresti non volerlo fare è se ci sono dei limiti tecnici per farlo, ad esempio se ci sono molte chiamate chatty tra i due microservizi che devono accadere per risolvere una richiesta del client. Questo potrebbe essere il caso, ad esempio, se si desidera fornire un servizio client che ottimizzi l'analisi "best fit", sia per selezionare i mobili sia per posizionarli e nel fare ciò è necessario selezionare un pezzo e posizionarlo in molte combinazioni. In tal caso, prenderei in considerazione la possibilità di realizzare un microservizio "Room Design" che gestisca internamente tutto ciò che potrebbe consentire di ottimizzare il database e le query e così via.
