| Image by John McArthur via Unsplash Copyright-free
At WorldRemit, the Platform Rewrite Project that we worked on was one of the largest and most demanding projects in the company. Its aim was to modernise the architecture of the entire system to adapt it to the growing needs of the company. One of the subject areas to rewrite was the Pricing system.
Since March, the Friction Team has been engaged in helping Pricing Team in the Pricing Rewrite Project. One of the first milestones to be achieved was the Pricing Dispatcher API.
The brand new part of the system (the rewritten one) and the older one have to work simultaneously for some interim period of time. This interim period of time is necessary for iterative rollout of the new Pricing System. The rollout can’t be done atomically due to the risks that may arise when one of the new components experiences stability issues. The idea is to switch corridors one by one to make sure that the components behave as expected, meeting the business needs.
This was one of the milestones that had to be completed so that the old-part and the new-part of the system could work in parallel - implementation of the Pricing Dispatcher API. The challenges to be overcome were as follows:
- Create price calculation for transfers made in new and old system
- Support functionalities implemented in the new system but not implemented in the old one
The Pricing Dispatcher API is responsible for dispatching the following functionalities:
- Retrieving primary pricing
- Retrieving interim pricing
- Creating interim pricing
- Checking calculations against given corridor configuration
Let me explain the above terms.
Primary pricing is a calculation displayed to the user at the initial stage of the process of calculating fees and exchange rates, when not all the calculation parameters are selected by the user.
Interim pricing is a calculation displayed to a user after selecting all the necessary parameters, such as: send country, receive country, send currency, receive currency, send amount, payout method and correspondent. It is created each time the user changes the parameter.
The image below demonstrates the connections between the dispatcher, and the old and new parts of the system.
Pic. 1 Connections between Pricing Dispatcher and both old and the new (rewritten) part of the system
As you can see in the image above, internally, the Pricing Dispatcher API uses a cache that stores information about which system should handle a given request. The Cache is based on a Redis key-value approach, where the given key is a corridor or pricing identifier, while the value represents one of the systems - old one or the new one. Furthermore, the Pricing Dispatcher exposes the functionality that allows easy change to the configuration of the system by a non-technical person. This will be vital when enabling the new corridors for our customers to benefit from the new pricing flow. The Pricing Dispatcher API is a temporary solution and it will be removed when all corridors are switched to use new pricing components; all the components calling Pricing Dispatcher will be switched to use a new pricing system, calls to Pricing Dispatcher removed and Pricing Dispatcher undeployed.
To summarise, the Pricing Dispatcher fits in perfectly into the concept of the services that meet the business requirements and the technical point of view. This concept allows us to kill multiple birds with one stone and easily introduce the new functionality for the customers to have a safe, stable and efficient process of enabling it. It is worth investing some time to implement such solutions as they have a significant impact on WorldRemit services while minimising the risk of instability of new functionalities.