Current architecture design as discussed starting 16/04/2020
This is the current view of how the service will work, with the back end making calls out to TIS Core to pull in data not duplicated in Revalidation.
The disadvantage with this approach is the tight coupling between the back end and TIS Core which means routing complexity, monitoring and recovery is added to the back end. Managing messages to other services should not be the responsibility of the back end.
The complexity of the back end will be increased each time it needs to talk to another service, e.g. Self Service for Form Rs or future GMC Connect APIs.
Long term design featuring a message broker
In the long term, integration could be performed using an off the shelf product, such as AWS MQ and Apache Camel.
AWS MQ integrates with Apache Camel and can be used to provide a sophisticated message broker service which supports multiple messaging patterns out of the box. Implementing this solution will de-couple micro-services from each other, allowing greater flexibility when it comes to changing existing services or adding extra services that need to be consumed.
With our current, envisaged configuration there would be very little custom code required to be written for the integration service. Most of our requirements would be handled by configurable settings in Camel.
Single request/response timeline
This diagram shows the path a request takes through the components of the service in the case of a request for dynamic data from the back end. The diagram illustrates the use of a controller, but the concept is the same where no controller or a broker is used.
The steps are
The client makes a request from the internet
Route 53, or other DNS directs the request to the Revalidation service
The WAF checks the incoming request is acceptable
API Gateway routes the message to the controller
The controller routes messages to the back end and TIS Core via private API Gateway calls
The back end and TIS Core send their responses back to the controller via the gateway
The controller aggregates the response and returns it to the public API Gateway
The public API Gateway sends the response back to the client via the WAF and Route 53.
Current Implementation
This is the current implementation in stage-revalidation as at Fri 24/04/2020:
API Gateway vs Application Load Balancer (…Draft…)
There are a number of pros and cons associated with using API Gateway (APIGW) vs Application Load Balancers (ALB).
Advantages of APIGW over ALB:
APIGW offers more features than ALB, such as request/response mapping, throttling, fine grained authorisation checking etc.
API Gateway is paid by usage and is cheaper if there are less than 100 requests per second
Advantages of ALB over APIGW
ALB is generally easier to configure
ALB is an hourly charge + usage which is cheaper to run if there are over 100 requests per second
HTTP to HTTPS redirection can be performed by the ALB. This is not possible with APIGW where it has to be done in Cloudfront or by the web server inside the VPC.
0 Comments