Skip to content

Arch Forum 2023-10-12

Participants: Andy, JD, Liangxiong, Shakib, Thani, Victor, Zak

Agenda

  • Arch forum
  • UserId vs ExternalUserId
  • Event Design - Property Naming
  • Event Design - Number of Events
  • RabbitMQ next steps

Notes

Arch Forum: First we had a short discussion around Arch Forum meeting itself. Andy raised a desire to have the agenda in advance, which would be helpful. Victor agrees, its "just" a matter of planning it better… We also discussed the format, with Thani and Liangxiong leaving, a new EM joining etc there is room to rethink this meeting. One reason to have a smaller group is to encourage everyone to speak and be able to have good discussions, which can be difficult in a large all-backend meeting. No specifics were decided, but Victor will continue to discuss.

UserId vs ExternalUserId: During planning of the Cashback project, a question arose if we should send them UserId or ExternalUserId. We could quickly conclude that ExternalUserId was a mistake (and recognized as such already a long time ago) and that we should only use UserId. However, in practice its not super easy to change, since Braze has the ExternalUserId and not UserId. Anyway, we should try to move it over to UserId as well.

Event Design - Property Naming: Victor had two questions about Event Naming. Why do we have to specify the name of event in Message Attribue ([Message("topic-name-goes-here", "EventNameGoesHere"] when we could easily get the class name? No one could see a reason except for some special cases when the class is renamed, but we want to keep the event name. Platform does not currently support this, but it could be easily added.

Next, and more importantly, we looked at the property naming. Why do we use JsonProperty to override the name to camelCase (from default of PascalCase), or in some cases snake_case? It is actually not necessary to use JsonProperty if we are happy with the default (which is PascalCase). Victor had also checked with Data team, and they also prefer PascalCase! Given this, we concluded that for new events, we should standardize on using PascalCase (just skip the JsonProperty attribute) for properties. (Events that we already have does not need / cannot be changed). Please see our Design Guidelines for this and other considerations.

Event Design - Number of Events: Finally a more tricky event design question. In the address change project, we will expand the AddressChangedEvent. The basic question raised was if changing the actual address (e.g. zip, state etc) should use the same event as changing the status of it (verified, unverified). In general, the data team prefers to have fewer types of events, and that is also how we have changed some other parts like wallet and remittance. However, there is a limit, obviously we need more than a single BackendChangedEvent which is published on anything. In many cases, it is more convenient (and scalable) to have a little more granular events for backend (an area might be interested only in address verification changes and not the actual addresses).

In the end we could not formulate a good general guideline, it is case-by-case. There should be one event for each thing changing, but if an address and its verification status is two separate things or a single thing is not clear-cut.

RabbitMQ Next Steps: Last couple of minutes we discussed how to move forward with our migration of ServiceBus to RabbitMQ. Not a long discussion, but at least in terms of implementation we believe that using the official RabbitMQ client (and not MassTransit or similar) is the best way given our experience with rewriting the ServiceBus client during the summer.