Bexs Gateway - Client Setup
Reference Documents
| Reference | Document Location |
|---|---|
| Product Document | New Product Design Committee - EBO for Brazilian Clients |
| Bexs Gateway - RFC I | First RFC describing the overall architecture |
| Bexs Gateway - RFC II | Second RFC describing the liquidity |
Problem Description
Bexs Gateway (BGW) is the main component to enable BRL trading capabilities to Ebury clients by leveraging Bexs’ services and infrastructure. According to the architecture design of the BGW, it will handle requests for creating and managing trades with Bexs. Nonetheless, both sides (Ebury and Bexs) have their own entities and registers for clients. Bexs API will only accept requests with reference to their clients' registers (customer_id), then at some point, there must be a correlation with the Ebury Client registers (client_id).
Background
Ebury has acquired Bexs in order to provide FX solutions to Brazilian companies. An RFC has been published containing the overall architecture of the service named Bexs Gateway and another RFC also describes the design for the quoting capabilities.
As a complement to that work, this document aims to provide the details for the setup of a client. This process should guarantee that Brazilian client registers created on Ebury side are in sync with the ones on Bexs side and there is a valid mapping between those two entities. In that way, it will be possible to request Bexs capabilities from Ebury systems.
Solution
BGW will be responsible for the synchronization of the two domains. In order to synchronize Client entities, BGW should be aware of changes in data sources of both systems.
For the Ebury part, BGW is going to consume the Kafka topic, which produces detailed change events of Ebury clients. Client events will be stored inside the gateway’s own relational database.
Bexs provides Webhook services in order to publish change events related to client and exchange entities. A new webhook consumer service will be created inside of Ebury's K8s system, and this service will be registered to Bexs as a webhook consumer. Retrieved webhook requests will be changed to business events which will be finally consumed by the BGW.
Having the two systems' client/customer-related events together, a separate service within BGW domain will create mappings between the two systems using their unique identifiers for every new onboarded user.
Apart from default onboarded client synchronization, there is going to be a one-time operation in which legacy clients of Bexs will be manually mapped into Ebury records. This action will be executed right after the successful production release.
Service Ownership
| New Service | Service Name | Service Owner |
|---|---|---|
| Yes | Bexs Gateway | LMI Team |
| Yes | Bexs Webhook Consumer | LMI Team |
| No | BEXS Webhook Services | Bexs |
| No | BOS | TFT Team |
Caveates
Apart from default onboarded client synchronisation, there is going to be a one-time operation in which legacy clients of Bexs will be manually mapped into Ebury records. This action will be executed right after the successful production release.
Operation
Bexs Webhook Consumer is a new service, which is introduced with this RFC. The service is going to be available for external use. It is going to be restricted for Bexs Webhook Services use only. Bexs Gateway and Bexs Webhook Consumer services are going to be maintained and operated by LMI team members.
Disaster recovery plan is having hourly backups, and recovering all data from the save points whenever it is needed.
Security Impact
Refer to Bexs Gateway RFC
Performance Impact
N/A
Developer Impact
N/A
Data Contracts
- No changes on predefined events.
- New Kafka messages will be published from Bexs Webhook Consumer to a specific topic, which will be consumed by Bexs Gateway.
Deployment
This is going to use the same deployment pattern described with Bexs Gateway. The inbound gateway, Bexs Webhook Consumer will have its own deployment pipeline on Jenkins, so it can be deployed separately.
Under AWS k8s with three environments. Deployments with k8s: - DEV: DXP cluster. local environment for developers. - STAGING: Integration with providers in staging. - PROD: Live integration with real customers.
Dependencies
Bexs’ Webhook notification services should be tested and available before staging and production releases of the project.
Based on RFC Template Version 1.1