Skip to content

Arch Forum 2024-08-22

Participants: Backend devs, Victor, Zak, Magnus, Andy

Agenda

  • 0 Deadletter vision recheck
  • RabbitMQ design
  • TransactionId Idempotency
  • Regression Test User Creation for Lithic

Notes

0 Deadletter vision recheck: This looks much improved now. Three areas got homework to review their deadletters that are old: MoneyFlow.Payment, Locations and AchFunding. They all had dead letters more than a week old.

(Cash Deposit also had leftover deadletter from the big Galileo incident, but there we have a need to keep them maybe a week longer).

RabbitMQ design: For RabbitMQ we will change the layout of queues, and naming of events:
- Each unique event/message will have its own RabbitMQ exchange (exchange is similar to service bus topic). This will be named after the MessageAttribute.Name.
- Each subscriber to event/message will have its own RabbitMQ queue, connected to the event's exchange. The queue will be named ExchangeName.ServiceName.
- The topic part of the MessageAttribue will be deprecated.
- Unless special circumstances, the name given in MessageAttribute.Name should follow this pattern <AreaName.EventClassName>.
- We should update all MessageAttribute.Name before we go live with RabbitMQ, since it will be difficult to do afterwards.
- Once we are live with RabbitMQ, we can update Auditing to use the MessageAttribute.Name instead of class name for Data Warehouse and Risk. Data team thinks it would be a good update, and have said they want updated names.
- Existing naming is documented here: https://docs.google.com/spreadsheets/d/1Swq1xflVenD2PMrHST3odN1wBWSOKevSROERf8VIYxE/edit?usp=sharing

Full example

The class

[Message("TestMinority", $"{Area.Name}.{nameof(TestMinorityMessage)}")]
public class TestMinorityMessage : IMessage
{
//
}

The exchange then becomes Platform.TestMinorityMessage and if platform tests listens for this, it will use a queue like this Platform.TestMinorityMessage_Majority.Platform.Test.Service

Additional data of existing events in servicebus:

  • Servicebus itself uses Topic, but not classname/eventname.
  • Risk uses classname
  • DW uses classname
  • Logs uses classname as endpoint
  • Logs uses topic+classname in message
  • Logs uses topic as service
  • DD uses topic for servicebus metrics
  • DD uses lowercase class name for minority.response:action
  • DD uses topic for minority.response:target
  • DD uses Kpi string value for event metrics (e.g. KpiValues/KpiTag)
  • When classname differs from eventname, most often eventname is the classname simplified.

TransactionId Idempotency: Background from Slack message by Ling:

To all areas call Transaction service, we are considering adding a new property TransactionId to all transaction requests and make it as Idempotency key, it means all areas need to set it (at the beginning for backward compatibility it's not mandatory). The purpose of this property is preventing Transaction service to process same request multiple times. So for same request the TransactionId should be same. For example for same barcode in cashdeposit, the CreditFunds transactionId is unique. We will bring this topic to Architect forum tomorrow so you have some time to think about the impact to your areas.

This means
- Each area that want to make a transaction will generate that tranasaction's Id (the guid) itself.
- A transaction is idempotent based on its transaction Id, it is safe to call transactions multiple time with the same transaction id, only one (normally the first) call will succeed.
- On errors from transactions, an area can, if they want, retry the call. They must retry with the same transaction Id, this way at most 1 transaction will be created.
- If there's an unclear response from transactions, like a timeout (5xx errors, timeouts etc), the requester must not assume the transaction was not created (but also not assume it was created). Instead it should do a retry, wait for transaction completed or do other action based on its specific business logic needs.

Magnus noted that it would be good to have a (tight) deadline for when all areas should be reviewed and updated to use this way of creating transaction ids.

Regression Test User Creation for Lithic: Rasmus shared that he has added the possibility to set the ledger type to Lithic (in addition to the default Galileo) in Regression tests, to make it possible to create users using Lithic instead of Galileo. It would be good if we could update tests everywhere to be parameterized on this , so that relevant tests run both for Galileo and Lithic, and therefor quickly make us cover a lot of Lithic functionality with tests.