4 ms·
None of this is unique to payments or the financial sector. And it is bizarre to me that you could run a payments system without high-availability or immutabil
by threeseed 3y ago
None of this is unique to payments or the financial sector.
And it is bizarre to me that you could run a payments system without high-availability or immutability at its core.
Also putting logs in a database alongside your core data is such a bad idea. There are plenty of solid, proven systems for log management that allow you to correlate against other databases. And it avoids the issue of you wasting limited write I/O on a non-priority task.
- rrr_oh_man 3y ago> And it avoids the issue of you wasting limited write I/O on a non-priority task. Is it really an issue, though, in most cases?
- threeseed 3y agoFor a database. Absolutely.
- anonzzzies 3y agoIn how many instances though? This sounds like premature optimising. We are not all Stripe; many companies making millions, but not billions, would have an easier life without doing more work or paying a fortune to niche saas companies for these type of things.
- rrr_oh_man 3y agoFood for thought: https://news.ycombinator.com/item?id=39276069 https://news.ycombinator.com/item?id=39276069
- pgr0ss 3y agoHi, I’m the author of the blog post. > And it is bizarre to me that you could run a payments system without high-availability or immutability at its core. I’m not sure what you’re referring to here as my post didn’t really go into these topics. > Also putting logs in a database alongside your core data is such a bad idea. I’m not suggesting putting all logs into the database. I’m suggesting that for a certain type of info (that is often logged), I find it more useful to put it in the database instead.