71–80 of 112 posts
This is a nit but is there a better way to say “RDBMS databases?” It feels like saying “ATM Machine”. Could we just say “relational database” or “state of the art database management system?”
A database that just got developed could be called a TardyBMS… I’m sorry I’ve drank too much coffee this morning.
Have built a fintech startup here in Germany ten years ago. The article mentions lots of important things. Here‘s another one: Time synchronization. It is incredibly important in fintech applications for a number of reasons: 1. *Transaction Ordering:* Financial transactions often need to be processed in the order they were initiated. This is especially crucial in high-frequency trading where trades are often made in…
How clock synchronization protocols can experience unaligned network partitions, where the ledger database cluster is able to continue running, but now with the risk of unsynchronized clocks and far-future timestamps, which can in turn then lead to money being locked up in 2PC payment protocols.
We therefore spent considerable effort [0] on clock synchronization in TigerBeetle, not for the consensus protocol—we never risk stale reads or take a chance with clock error bounds—but rather simply for accurate audit trails and to keep inflight liquidity from being locked up if transactions take too long to get rolled back.
[0] https://tigerbeetle.com/blog/three-clocks-are-better-than-on...
Earlier quoted context omitted.
I have worked at banks and fintechs for the past 30 years and honestly have never used anything but a doubles for money with no issues (and a simpler code base.) I understand the sentiment and the potential issues, but it's really kind of domain dependent.
Is storing $1.05 really that much simpler than storing something as 105? Use a long to store money, pretty easy.
Earlier quoted context omitted.
For example 16.10 is not exactly 16.10 in IEEE floating point. When you do enough operations, and depending on the order of operations, you can wind up several cents off. That sounds small, but can be enough to give your auditors heart-burn. COBOL does BCD arithmetic, (not really but at least conceptually), and it's penny accurate to 31 digits (as per the standard - implementations may have greater accuracy). Frankly…
It would be neat to have a fundamental "money" primitive alongside int, float, string, etc. It might not be simple to implement, though. Off the top of my head, * Can you confidently say that $100>¥10 in an offline environment? * You'd need to support different bases for splitting units to deal with eldritch values such as farthings. * Where is the line drawn? Is a Bitcoin a valid currency? A gold Krugerrand? A bundl…
https://hackage.haskell.org/package/safe-money-0.9.1/docs/Mo...
I’d also add: — If you’re using JSON to pass around monetary quantities (eg. from the frontend to the backend), put them in strings as opposed to the native number type. You never know what the serializers and deserializers across languages will do to your numbers (round them, truncate them etc.). — Start recording the currency of the transactions as early as possible. It can be a separate column in your table. — Use…
> — Use TIMESTAMPTZ. Always. When you’re using JSON to pass around datetime data, Use ISO8601 date and time with offset info, always. e.g. "transactionDate": "2023‐06‐28T15:55:22.511Z"
Next to that, ensure transactions are immutable, and ensure reporting is idempotent: Close your periods and generate reports for them, when you regenerate the report it should be identical.
This is more domain tips. A lot of technical tips hold for non fintech too.
Earlier quoted context omitted.
> Use ISO8601 date and time with offset info, always. I think that's just sufficient for all use cases everywhere. I've been a software engineer for almost 25 years and, of all the universal truths I've encountered, implicit and unintended changes to datetime offset are the ones I've seen at every single job.
> I think [ISO8601 date and time with offset info is] sufficient for all use cases everywhere. TLDR: Also, which timezone is used (not quite the same as offset) really does matter--UTC is great but you can't use it everywhere. ________ One of my favorite simple examples of this "here be dragons" for the new developer: Any system that schedules a future calendar-event. Such events are typically pegged, implicitly if n…
Good catch!
One more: Timezones Various platforms use: UTC, the user’s timezone as set in their dashboard, the user’s detected timezone, the timezone of the server that is generating the reports. Aggregating or reconciling data from different platforms can be a pain if the timezones aren’t clearly indicated. I’ve had bank statements that didn’t agree to CSV exports of the same data because the servers generating the two reports…
We only had a dozen issues due to it so I believe it worked pretty well compared to the war stories I heard from comparable companies in the fintech space.
Earlier quoted context omitted.
Do you always put the currency behind the number? I know some countries prefer the currency infront (e.g. USD), others behind (EUR). But since this is not a human visible field, this is probably irrelevant, right?
I think I looked at this when I laid it out: https://ux.stackexchange.com/questions/9105/international-cu... So we put the ISO code at the end and ignore whitespace. But including a prefix sign as with `€1.234.567,89 EUR` would break it.