As the name suggests the Circuit breaker design pattern is used to stop the process of request and return with the response if a service is not working.
This design pattern can improve the stability and flexibility of an application.
In a distributed environment, calls to remote services and resources can fail due to transient faults, such as slow network connection, timeouts, or the resource being over-committed or temporarily unavailable. These faults typically fix themselves after a short period of time.
However there can also be situations where faults are due to unforeseen events, that might take longer to fix. These faults vary from partial loss of connectivity to complete failure of a service. In these situations, it might be pointless for an application to keep retrying an operation that is unlikely to succeed, instead, the application should accept that the operation has failed and handled this failure accordingly.
A circuit breaker pattern can prevent an application from repeatedly trying to execute an operation that’s likely to fail. Allowing it to continue without waiting for the fault to be fixed or the utilization of resources does not kill the CPU and memory.
It also enables an application to detect whether the fault has been resolved.
How does the Circuit breaker work?
A client should invoke a remote service via a proxy. When the number of consecutive failures crosses a threshold, the circuit breaker trips, and for the duration of a timeout period all attempts to invoke the remote service will fail immediately. After the timeout expires the circuit breaker allows a limited number of test requests to pass through. If those requests succeed the circuit breaker resumes normal operation. Otherwise, if there is a failure the timeout period begins again.
Circuit breaker design pattern
Consider we have Video Upload and View service when there is a failure in one of the services which triggers the Circuit open and enables the proxy service.
In the next article, we will see the Decomposition design pattern.
Before understanding what is Event sourcing design pattern is, let us see why & when do we use the Event sourcing design pattern.
All application uses data to maintain the current state of the data by updating it, In the traditional Create, Read, Update & Delete (CRUD) model a data is read, then make some modification to It, and update the current state of the data with the new values – often by using transactions to lock the data.
CRUD has its own limitations, below are a few such limitations.
CRUD performs update operations directly against the data, which slowdowns the performance and limits the scalability.
When multiple users read and updates the data, more likely conflict occurs since the update operations take place on single data.
Unless there is a separate auditing mechanism that records the state of data as history or the state of the data is lost.
Now, this is why & when we need to use an Event sourcing design pattern.
Event sourcing design pattern:
Event Sourcing gives us a new way of persisting application state as an ordered sequence of events. We can selectively query these events and reconstruct the state of the application at any point in time. Of course, to make this work, we need to reimage every change to the state of the application as events:
Event sourcing design pattern
Consider we have Order and Cart services, When the Client adds the item to the cart or remove the items from the cart, these are called events, These events must be stored in order to maintain the changes made to the cart.
The events are persisted and published into the Event queue. Where the other services will subscribe to those events to get the updated state of the cart.
Consider you add the item to cart from Mobile App, then you login to website via PC and make some changes to the cart, these are captured as events and maintaining the seamless experience when accessing the cart in different platform.
In the next article, we will see the Branch design pattern.
Today we will see what is API Gateway Design Pattern is.
What is API Gateway Design Pattern?
Microservice is built in such a way that each service acts differently on its own. So, when a web application is drilled down into smaller pieces there could be problems we face.
The problems are as follows.
How to get data from various microservices?
A different front-end application is required to manage the same database, just that it uses multiple web services.
How to respond with the data for different consumer to satisfy their requirement. So that we can have reusable microservices.
Handle multiple protocol requests.
Seems the list is small here, but in reality, it is even wider. The solution for these problems is to use the API Gateway design pattern. The API Gateway design pattern addresses many other problems apart from the ones mentioned above. We can also use this design pattern as a proxy service for routing the request.
API Gateway acts as the entry point for all the endpoints of the microservice, it can help in converting the various protocol request from one type to another. Also, it can disburden the responsibility of authentication/authorization in the microservice.
So, once the client sends the request, requests are passed through the API gateway which manages the entry point and re-routes the client’s request to the appropriate microservice. Then with the help of the load balancer, it distributes the client’s request to the microservice.
Microservice uses the service discovery which maintains the available microservices and their available entry points to communicate with each other
API Gateway Design pattern
In the next article, we will see Chained or Chain of Responsibility design pattern.