The Aggregator Pattern provides a way for a client to obtain combinations of data from each microservice of a microservice-based application. However it is not exactly the same as an API Gateway.
The API Gateway Pattern provides a way for a client to obtain combinations of data from each microservice of a microservice-based application.
The Factory Method pattern is extremely useful when a class cannot decide in advance the class of objects it must create. The task of specifying the objects is given to the subclasses, instead. The class delegates responsibility to one of several helper subclasses, and the user localizes the knowledge of the delegate. Factory Method Pattern
The reactor pattern already underpins many of the platforms you use today, and is now one of the most common ways to deal with concurrency.
The bulkhead pattern enforces the principle of damage containment and provides a higher degree of resilience by partitioning the system.
The throttling pattern is used to allow a service to maintain a steady pace when process multiple customer requests. Throttling can be implemented using multiple strategies: •Rejecting requests from an individual user who has already accessed the service more than n times over a given period of time. •Disabling or degrading the functionality of selected nonessential services
The Circuit Breaker pattern is used to check the availability of an external service, detect failures and prevent them from happening constantly. For example, if an application needs to retrieve data from an external service 100 times per second, and the service is unavailable (e.g., down for maintain ace or because of a hardware failure),
There are some consideration when using retry pattern: When there is an indication that the fault is not transient or unlikely for service request to be successful if repeated (for example, an authentication failure caused by invalid user credentials or bad request send to service , e.g., HTTP status code 4xx received from the service), the application should not try to retry , but abort the operation invocation and report a suitable exception. If the specific fault is unusual or rare, it may have been caused by extraordinary circumstances such as a network packet lost in transit. In this case, the application could immediately retry the same request again because the same failure is unlikely to happen again and the request will probably be successful. If the fault is caused by issues such as service being not fully responsive (e.g., “service busy “) the service consumer should wait for a suitable time before retrying the request.