Proposal to replace the current endpoints implementation

[elnyry-sam-k]

Request Summary:

Proposal to replace the current endpoints implementation in Mojaloop

Request Details:

• Deadline: <When do we need a decision by?>
• Impact (Teams): <If your proposal is accepted, what team(s) will be affected by it?>
• Impact (Components): <If your proposal is accepted, which components (e.g. APIs, docs, codebases) will be affected by it?>

The motivation:

1. Reverse proxying to FSPIOP paths is better as an FSP concern- i.e. routing /transfers /quotes etc. is something the FSP should manage themselves.
2. In my experience of implementations, that is exactly what happens: all traffic for a given FSP goes to a gateway managed by the implementation and is sent to a single FSP endpoint.
3. The current endpoints implementation needs improvement 3.1. The only way to invalidate cache is to delete a pod 3.2. There is a tension between database load and cache freshness

I'd propose however, that instead of doing the work to improve the current endpoints implementation, we should remove it completely and route requests for any given FSP to a static host: the FSP's name.

How would it work? In Kubernetes, one service per FSP would be required. Similar to the following:

apiVersion: v1
kind: Service
metadata:
  name: payerfsp
spec:
  type: ExternalName
  externalName: payerfsp.example.com

The switch would route all requests for payerfsp to the hostname payerfsp. The above service implementation means all requests for payerfsp route to payerfsp.example.com. These services could be optionally created by the ML helm chart. The services could be managed by an operations team.

Benefits:

1. No dependence on the database at all
2. Can remove the existing endpoints implementation, simplifying Mojaloop, reducing bugs, reducing maintenance
3. Can leverage existing high-quality DNS servers
4. This is mature, high-quality software that Mojaloop does not need to maintain
5. Superior cache configuration, amongst other things
6. Declarative configuration
7. Very easily supported in Kubernetes, docker, docker-compose
8. Very easily supported by the current Helm chart, or an auxiliary chart

Criticisms so far:

1. If FSP hostnames change frequently, it might be preferable to have this configuration in the application.
2. If a user does not control their DNS resolution, this solution will not work. I will mention that I don't think this is a realistic scenario.

One interesting suggestion from Vijay Kumar (@vijayg10 ) was to route all requests to a single hostname, then have the application at that hostname perform any routing required. In this case, every request for, say, payerfsp would be sent to http://my-gateway/payerfsp . Similarly other FSPs to http://my-gateway/$other_fsp. This means only a single service would be required. For development purposes in Kubernetes, this would require a little magic that could likely be handled by a combination of an ExternalName service (very similar to the above example) and an ingress. In docker or docker-compose it might be slightly more tricky- perhaps a reverse proxy. Vijay's suggestion would better reflect real usage in production systems, and is simpler in production; but has a relatively small complexity cost in development environments.

Artifacts:

• [ ] Artifact to consider [@Contributor]

Dependencies:

• [ ] If Applicable

Accountability:

• Owner: Matt Kingston (@partiallyordered )
• Raised By: Matt Kingston (@partiallyordered )

Decision(s):

- **Approved By:** ### Details - [ ] Actual decision made as a result of discussion ## **Follow-up**: - [ ] Actions to implement the decisions

[partiallyordered]

Summary of the DA meeting:

General agreement with the proposal. A suggested implementation pathway:

1. Implement in ML v14 (for example), but have a DNS endpoints implementation default-disabled, available behind a flag. Notify users of availability of implementation. Notify users that this will be the default in future, and that the legacy implementation will be deprecated in future.
2. In ML v15, have the DNS-based endpoints implementation default-enabled. Have the legacy implementation default-disabled, available behind a flag, officially deprecated. Notify users that the legacy implementation will be removed in the next version.
3. In ML v16, remove the legacy implementation.

[mdebarros]

Update 2022-02-02:

• Decision is to address this issue as part of the vNext workstream, where it will be managed by the Platform Configuration BC which is responsible for propagating/sharing configurations to other BC/Components, and sending notifications to invalidate caches.