0

We build up a microservice architecture which is called from above by a REACT SPA. All is deployed in the AWS Cloud, that is to say in an AWS EKS (K8S). We have at most 600 users in parallel.

Do you see an urgency to apply primarily a sync over async (via messaging) communication in such a high performant K8S environment instead of a plain sync REST communication equipped with connection and read timeouts and Circuit Breakers? From my perspective this can be handled easily by REST and messaging should only be applied for the fire-and-forget (one-way notification) paradigm. Furthermore, REST has a better Interface Definition Language (OpenAPI) and we can profit of all what HTTP provides, e.g. all the common HTTP status codes which everyone understands. I'd miss a HTTP mocking library like WireMock to stub responses; with messaging channels this might be awkward.

Is it still advisable to favor sync over async over REST, even deployed in the Cloud and K8S?

kladderradatsch
  • 101
  • 2
  • Be careful about transitive calls (service A calls service B, which then has to call service C to complete A's request). These can lead to complicated cascading behaviors and oscillations, where read timeouts and circuit breakers are not enough on their own to resolve the issue. – user1937198 Jun 03 '23 at 13:34
  • A system that allows for queuing between services has more elasticity to avoid those oscillations and cascades. – user1937198 Jun 03 '23 at 13:34

0 Answers0