Arch Forum 2026-07-02¶
Participants: Backend Devs and Victor
Agenda¶
- Arch Forum in the autumn
- Platform news
- Redis removal
- Single EventStream exchange/queue for auditing
- New deadletter handling
- DB
Summary¶
Arch Forum in the autumn¶
Arch Forum takes vacation until August. To think about until after the summer:
- It would be great if we had more presentations by others than Victor.
- What do you think of our current architecture? We will likely do some kind of arch retrospective after the summer.
- In general, what topics would you like we cover in the Arch Forum meeting?
Platform news¶
- TransactionalSet and TransactionalDelete for Firebase / Ling
- Platform now support Rabbit 4.3.x
- DB migrations now always run the platform sql before area specific migrations
- Redis is now deprecated and removed from platform
Single EventStream exchange/queue for auditing¶
The idea is to have a single exchange/queue for auditing, so that all events by default are forwarded to the DW.
New deadletter handling¶
The idea is to have a single deadletter exchange/queue. Hydra listens on the queue, and persists the deatletters in
its database. Hydra then have a UI were we can more easily manage the deadletters.
The single deadletter queue is available on stage except for the management UI.
Demo of POC.
Notes from the meeting:
- A export everything including body feature would be good (i.e. to easily get AI to help)
- Filter should support wildcard search, e.g filtering on Wallet queue name would return all queues matching Wallet
Redis Removal¶
Why did we want to do this?
- It was not needed.
- Every extra dependency have a cost, even great software like Redis, for example
- Need to have redis locally to run tests
- Need to update redis packages
- One more thing to learn
- Higher chance of Azure issues
Any effects on the migrated areas?
- https://app.datadoghq.com/notebook/14895874/redis-removal?refresh_mode=sliding&from_ts=1782735998558&to_ts=1782908798558
- https://minorityv2.kb.us-east4.gcp.elastic-cloud.com/app/lens#/edit/bd406db8-4d3f-4ef6-b198-a40be09bf538?_g=(filters:!(),refreshInterval:(pause:!t,value:60000),time:(from:now-24h/h,to:now))
Duration before/after
CPU usage before/after
DB¶
Given we have had two recent lockups of the Transaction table in TransactionDB, here's a refresher of how to deal with the DB.