Skip to content

Arch Forum 2023-10-26

Participants: Backend developers, EMs, Andy, JD, Victor

Agenda

  • Intro, what is this for?
  • Merge Bank & MF Auditing
  • Should we design areas for "selling"?

Notes

Intro, what is this for?: This was the first meeting with updated participants. Since both Thani and Liangxiong will leave Majority, we changed the format to include all backend devs. A short meeting intro followed.
- We discuss (and decide on) general Technical/Architectural topics. Especially those that concern more than one area, and even more those that span the two backend teams.
- For examples, see previous meeting notes.
- If anyone has topics they think are suitable, please let Victor knew in advance.
- The meeting is optional.
- If someone is critical, Victor will ensure he/she attends.
- There will be meeting notes to catch up.
- Given it's optional, and the purpose is to have active discussions. If you do not feel the topics of the day are interesting / there are too many discussions / busy with something else, do not hesitate to skip the meeting.

Merge Bank & MF Auditing: Tracked in MIB-8979. Given our recent unification work, it seems reasonable to merge Bank Auditing (BA) and Moneyflow Auditing (MA). A discussion around what the two auditing services do. BA requires manual registration of events to listen for, and enrich the events with some data (External UserID) for Braze. MA automatically take all events, but instead the event publisher need to publish specifically to MA.

A question raised was if we can send all events to DW?
- In load/cost, it should not matter. Storing events in the EventDump table adds a minor cost.
- Some events are useless for DW. But default should be to send. Therefor, we would need to add a No DW Attribute.
- With RabbitMQ it's not difficult to implement a listener on all topics to catch all events without any source generation, reflection or manual event registration in new Auditing.
- Some stats retrieved after the meeting: on 2023-10-26 we logged 4024577 EOUT in Kibana, and stored 3390598 events in DW EventDump table (~85% of all events).

Given this, we should
- Do the auditing merge together with RabbitMQ migration, since there's no point to do anything for ServiceBus or old RabbitMQ implementation
- Let the new auditing take all events by default.
- Create a new attribute, "SkipDWAttribute" (name up for discussion), that tells the new auditing to skip forwarding the event to DW.

Should we design areas for "selling"?: A long discussion around how independent areas / collection of areas should be. Some cases in backend (Risk, MF services, Rate) we have kept more separate than others. For example, calls to these areas pass through the API layer, sometimes goes "outside" the internal network etc.

  • We covered the history, why is it like it is (for example there was at one point an idea to actually sell some MF services and the idea that Rate could be used by Rebtel).
  • JD expressed that in his view it was a mistake to let other areas call risk internally instead of through public DNS.
  • In some cases (like MF) there's a common view that there's too strict separation.
  • If/when we become a big tech organization, it's an advantage to have good separation of different groups of areas to be able to scale.
  • At our current size, it makes sense to keep as much as possible consolidated.
  • Some reasons to align
    • Performance (probably not a very strong reason, even passing through public internet and through an extra layer of API should not add more than a few ms at most)
    • Security (It's not clear how strong this argument is, but in general we have more than good enough security)
    • Consistency/simplification (This is the strongest argument. Each special case, each extra layer of stuff, adds complexity that ultimately takes developer thought and developer time to deal with)
  • When we argue for more alignment, we need to better present the business case. Why do we want to do it, and if possible have actual data to back it up with.