Skip to content

Arch Forum 2023-06-01

Participants: Johan D, Liangxiong, Shoaib, Thani, Victor and Zakarya

Agenda

Notes

Redesign how web and Fees & Promos depends on WebApi: The first topic of the day was the dependency backend have on majority-web-api (and as a result also on Fastly, our CDN). This dependency meant that when Fastly had an issue, then also Fees & Promotions experienced the same from some functionality.

Basically, the dependency chain was F&P -> Fastly -> WebApi -> Rebtel and Web -> Fastly -> WebApi -> Rebtel. As a workaround during the Fastly issue, we rerouted traffic so that F&P could do requests directly to WebApi. However, in general backend should not depend on WebApi for data, especially not such data that is available elsewhere in backend (e.g. country lists or Mtu data). Instead, F&P should get this data from the relevant other backend service, such as Mtu or Remittance. In addition, since this data is in backend, the website should also go to backend to fetch the data, and not query WebApi/Rebtel.

This is tracked here (and the linked tickets) https://majority.atlassian.net/browse/MIB-7955

Move Braze logic from User to Braze Area: The second topic was from Moneyflow/Remittance, which have a need for Braze IDs which today are only stored in User area (which has the main Braze functionality). Instead, the suggestion is to move Braze logic and data from User to Braze area. We could quickly conclude that this is the correct thing, and just a matter of priority. Moneyflow will start to add the required functionality to Braze area, and once in place, other areas using Braze can be updated to not depend on user. Finally, when all uses are fixed, the Braze logic can be removed from User.

This is tracked here: https://majority.atlassian.net/browse/MIB-7923

Elastic log retention increase: Thani brought up our log retention in Elastic/Kibana. Some times there are support cases that started several weeks ago that are difficult or impossible to solve unless we have logs. This can for example happen on Remittance when a customer started remittance several weeks ago, and then it expired, and finally they contact support and after 25-35 days a developer takes a look. After a look at costs, we could decide to increase it to at least 30 days.

After the meeting, Victor and Moh added a "frozen tier" to the Elastic cluster, which increase the total size almost 3 times. To start with, we will keep 100 days of data in Elastic. Note however that searching more than ~20 days back can be quite slow, and it's probably best to limit the search to specific dates in those cases to speed up the queries. Exactly how it will perform is difficult to know in advance, so this is a trial.