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.
> 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.
In 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.
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.