21–30 of 74 posts
> but the default ring is more or less a single, global, object database for the entire bank. Is this really the case? I'm sure there are plenty of transactions that for umpteen different reasons must not be exposed on a global level.
I've seen similar inside large financial orgs - what struck me was how there are these huge amounts of people that spend their entire working life inside this alternate IT reality. It's not unlike SAP consultants where their skillset is tied to one company. Also...these things tend to have fuckin terrible documentation. Good luck figuring any of this out. And you can't google it and your AI is just as lost as you
I’ve had clients ring up about pennies… it can be crazy what some people are motivated by
> This is because clients generally do not ring up about pennies. I’ve had clients ring up about pennies… it can be crazy what some people are motivated by
Quite common in accounting, the accounting equation must balance, it's like a checksum
Earlier quoted context omitted.
Eh, to be fair, this post is about a _bank_, and the one you've linked is about _fintech_. They are not even close to the same space, even though they both deal with money. But also I suppose you may be saying exactly this?
to be fair, it is a fintech that wants to become a bank
>Applications also commonly store their internal state in Barbara - writing dataclasses straight in and out with only very simple locking and transactions (if any). Right out of the gates, it's crazy how this contrasts with Mercury's Haskell infra https://blog.haskell.org/a-couple-million-lines-of-haskell/
It sounds pretty similar actually. Barbara fills the same role that Temporal is doing at Mercury.
Barbara is a company wide database, it handles data storage.
When I read about internal app state being stored in Barbara I'm interpreting that the policy is for the data to be centralized for more vertical control.
While the Temporal thing sounds like if something is written, it's done so in a containerized like manner, and other processes can't just read it.
I think it is a pity they’ll likely never open source any of this stuff Of course, financial institutions have a lot of “secret sauce” - such as financial models - you’d never expect them to release. But this kind of underlying infrastructure isn’t really “secret sauce”
Earlier quoted context omitted.
It sounds pretty similar actually. Barbara fills the same role that Temporal is doing at Mercury.
I may be reading between lines, but temporal seems to be a virtual machine like the evm, it handles computation. Barbara is a company wide database, it handles data storage. When I read about internal app state being stored in Barbara I'm interpreting that the policy is for the data to be centralized for more vertical control. While the Temporal thing sounds like if something is written, it's done so in a containeriz…
It stores the app's work-in-progress state as well (probably as a blob full of serialised internal datastructures, at least in some cases):
> You write your workflow as ordinary sequential code, and the platform records every step in an event history. If a worker crashes mid-workflow, another worker replays the deterministic prefix to reconstruct the state, then continues from where it left off.
> When I read about internal app state being stored in Barbara I'm interpreting that the policy is for the data to be centralized for more vertical control.
That wasn't the way I experienced it, if anything it was the opposite: app developers would push to use Barbara for their internal state because it was easy: the app is already accessing it, the APIs are simple, and since it's just pickled objects you can just store your state without having to worry about serialisation (much) or ORM. Whereas policy and leadership would if anything prefer you to use a separate traditional database. The point of Barbara is to provide a unified interface onto "everything the bank knows", it's primarily for data that multiple teams use, not internal state owned by a single team.