Your problem is that you got in the wrong direction of designing microservices. In fact you are trying to solve the problem that most microservices system architects try to avoid: inter-communication among microservices.
Why do they try to avoid this? let me be clear that there are more than one way to implement this communication BUT doing so makes your system less resilient as one microservice depends on the other(s). Another important reason is that no matter what kind of solution we have, IT IS SLOW. One should not assume that the network is reliable, the servers are highly available and responsive. This hasn't mention that you are talking in the PHP context where every external service call requires your application framework, i.e. Laravel/Lumen to boot up and that's really really slow.
Now, what are the communication options do we have? What you did is using HTTP request/response communication which is one of the 2 options. HTTP is synchronous and participants in this communication is 1-1. In some cases, this is the right choice, i.e you rely on an external service to query data. But, again, avoid this as much as possible. In your case, your main service is trying to compose data from multiple sources, puts them in a big bag and throws it back to the client. If you revise the situation, your client can make 3 calls or 1 composite call to 3 separate APIs.
Each microservice has to be self-container and autonomous.
The other option is sending asynchronous messages. This communication pattern is used when you need to propagate data update through the system. Kafka or RabbitMQ are popular message brokers used to facilitate this kind of communication.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Your problem is that you got in the wrong direction of designing microservices. In fact you are trying to solve the problem that most microservices system architects try to avoid: inter-communication among microservices.
Why do they try to avoid this? let me be clear that there are more than one way to implement this communication BUT doing so makes your system less resilient as one microservice depends on the other(s). Another important reason is that no matter what kind of solution we have, IT IS SLOW. One should not assume that the network is reliable, the servers are highly available and responsive. This hasn't mention that you are talking in the PHP context where every external service call requires your application framework, i.e. Laravel/Lumen to boot up and that's really really slow.
Now, what are the communication options do we have? What you did is using HTTP request/response communication which is one of the 2 options. HTTP is synchronous and participants in this communication is 1-1. In some cases, this is the right choice, i.e you rely on an external service to query data. But, again, avoid this as much as possible. In your case, your main service is trying to compose data from multiple sources, puts them in a big bag and throws it back to the client. If you revise the situation, your client can make 3 calls or 1 composite call to 3 separate APIs.
Each microservice has to be self-container and autonomous.
The other option is sending asynchronous messages. This communication pattern is used when you need to propagate data update through the system. Kafka or RabbitMQ are popular message brokers used to facilitate this kind of communication.