Should an API Gateway Communicate via a Queue or directly to other μServices?

问题

I was wondering which of my two methods is more appropriate, or is there event another one?

(1) Direct

Direct communication between GATEWAY and μSERVICE A

1. UI sends HTTP request to GATEWAY
2. GATEWAY sends HTTP request to μSERVICE A
3. μSERVICE A returns either SUCCESS or ERROR
4. Event is stored in EVENT STORE and published to QUEUE
5. PROJECTION DATABASE is updated
6. Other μSERVICES might consume event

---

(2) Events

Event-based communication via a message queue

1. UI sends HTTP request to GATEWAY
2. GATEWAY published event to QUEUE
3. μSERVICE A consumes event
4. Event is stored in EVENT STORE and published to QUEUE
5. PROJECTION DATABASE is updated
6. Other μSERVICES might consume event
7. GATEWAY consumes event and sends response (SUCCESS or ERROR) to UI

---

I am really sorry if I misunderstood some concept, I am relatively new to this style of architecture.

Thanks in advance for every help! :)

回答1:

Second approach is a preferred way and is async approach.

Direct

In first approach your microsvc B and C wait for the event to get published . The scalability of this system is directly dependent on microsvc A. what if microsvc A is down or falling behind writing events to queue? it's like single point of failure and bottleneck. you can't scale system easily.

Events

In microservices we keep system async so they can scale. Gateway should be writing to the queue using pub/sub and all these microservices can use events at same time. system over all is more robust and can be scaled.

来源：https://stackoverflow.com/questions/56622485/should-an-api-gateway-communicate-via-a-queue-or-directly-to-other-%ce%bcservices