4 ms·
Hi So first of all, thank you for sharing your work, I'm sure it was a lot of fun building it and making it work! If you'll indulge me, I'll point out a few t
by eerikkivistik 7y ago
Hi
So first of all, thank you for sharing your work, I'm sure it was a lot of fun building it and making it work!
If you'll indulge me, I'll point out a few thoughts about application logic that handles money.
First of all, money related logic should be using fixed point mathematics in all places. In the case of EUR/USD fixed to 2 points behind the decimal point and in case of BTC and others, somewhere around 9-16 (can't be bothered to look it up atm). There is a cumulative error that is produced when using floating point variables. I'll be happy to share a link to a discussion, if you want!
The second thought I had was about using MongoDB for this use case. While it is great for getting started and MongoDB has made great strides at improving safety, it is still a suboptimal choice for handling financial transactions (logs or otherwise). I will also be happy to clarify why, if someone wants to discuss the matter further.
- squeaky-clean 7y ago> While it is great for getting started and MongoDB has made great strides at improving safety, it is still a suboptimal choice for handling financial transactions (logs or otherwise). Would you mind clarifying this last bit? The default settings are not ideal and you need to do some configuration, but if you know what you're doing MongoDB has been capable of safe data storage since 3.6? What else would make it suboptimal? Admittedly I'd probably choose postgres on a new project, given the many features. But in my dayjob I use MongoDB because of Org/Historical reasons and am not really aware of any problems that can't be mitigated. Is it just because you have to waste time mitigating common problems?
- eerikkivistik 7y agoSure thing. So most of the problems I have with using NoSQL type databases for financial data is related to the default settings and examples encouraging a model of programming, that will result in data loss, migration problems, race conditions, duplicate transactions. It's a bit like PHP in my mind, where you can write solid software, but in order to do so, you have to have very good discipline. I would rather choose a more constrained model, that forces you think about these problems and provides some safety out of the box. So in that sense you are right in your observation that my main issue with it is, that you have to mitigate problems, that shouldn't be problems. Then again MongoDB was never designed with those kinds of problems in mind and targets a completely different set of problems, which in itself is fine. Edit: I'll add a few more thoughts. Financial data in essence is relational. It is also well shardable if scaling is an issue. There are many constraints that need to be validated and it is a natural fit in my mind.
- bastawhiz 7y agoWhat are your thoughts on Stripe using Mongo almost exclusively?
- zajd 7y agoWhat makes you think Stripe uses Mongo almost exclusively?
- eerikkivistik 7y agoNot sure about the stack Stripe uses, but if they do use Mongo, then they I presume they made it work well enough with a sheer force of will and reimplemented many ACID guarantees in the application layer themselves. That is of course assuming, that they started with Mongo early on, when it was still a bit wonky. I would love for a Stripe developer to jump in and share some background!
- nayuki 7y agoBitcoin has exactly 8 decimal places. The terminology is 0.00000001 BTC = 1 satoshi.
- eerikkivistik 7y agoRight you are, consider me corrected.