How did we prepare for Albert’s multi-country transition?
As Albert Health, we established our application and systems in Turkey in 2018 and continued to develop them here. In 2022, we have 15+ customers and 10,000+ users. 2022 will be Albert’s first year becoming a multinational company, so what will we do as the software team?
Our Requirements
Health data is one of the most critical data types regarding the sensitivity of data types. GDPR laws include the retention of users’ data in the countries where the users are located.
In this case, it was not enough to have a database and backend system for the UK, the first country that Albert Health is going to branch out, but also a need to redirect patients’ data to the correct locations without disrupting the flow and make sure that the data is stored where the users are located.
Albert Router
After planning and roadmaps, we decided to add a new microservice layer to the existing systems. It’s called Albert Router.
In the existing structure, front-end applications were sending requests to back-end endpoints that were statically located in them.
In the new structure, front-end applications will first verify the region of the user with the Albert Router, and then have the back-end endpoint information according to the region information of the user.
If the user is new, that is, the region information is not kept by the Router, the Router will find the most accurate region information from the user’s IP address and return it to the front-end application and record it in its database.
Problems
The biggest problem we will encounter while creating this new structure was the processing speed of the system.
- The system would query the database to see if the user was registered before.
- In other words, each transaction would take time and the user should not feel it.
- If it wasn’t saved, it would find it in the user’s region and save it later. It would eventually return the information to the client.
- Again, during this process, there was a situation where the user’s region was found and a new transaction was created with the database.
On our list of requirements, we had to have a fast database and a framework or runtime environment that could do fast processing.
Solution
Fast DB: Redis
We decided to use Redis for this structure because, Redis was storing data in the form of key values and we only needed a database to hold the region information as opposed to the Unique ID information of the users.
In the future, the link of our article about Redis installation & configuration will come here, you can follow it by subscribing to our Medium page.
Spring Native
When we were considering this project, the Spring community had just released Spring Native from beta to a stable version. The point that Spring Native claimed was that it competed with Node.js in terms of processing speed and system startup time.
The result was that we would use Redis as the database and test Spring Native at the initial stage and replace it if we felt it was failing.
In the future, the link of our article about Spring Native installation will come here, you can follow it by subscribing to our Medium page.
Conclusion
After the design and installation of the system were completed, learn the limits of the system, we created a thread group over JMeter and started to issue test cases.
- 1000 registered users trying to log in instantly
- 1000 unregistered users trying to log in instantly
In order to create the most realistic test cases here, we produced different uids by adding the instant time information to the end of the unique id in the body we sent from JMeter.
{
"uniqueId":"user${__time()}"
}Here are the test results;
The geolocation API we use here causes us an average of 20 ms slowness for each request. As a total slow-down time, there is a loss equivalent to 40 ms on average.
However, if we consider that each user will go through this process once, the result for registered users is at the level we want.
