We are not doing the transactions, we are settling the market that the bets are placed against. We say something like "Player X scored the first goal" and the client then pays out the customers who made that bet and takes money from those that bet on a different goal scorer. If we get it wrong the client has paid money out they cannot get back (reasons) and then they have to pay out the correct bet, "Player Y is the first goal scorer". There are conditions that should make us delay announcing the settlement (goal being challenged / reviewed). It's not enough to know that a goal was scored but we need to be sure that the goal is valid. So we log like crazy to make sure we know why we made our decisions Around 50 to 800 events that may affect the settlement of a market occur per match so we can log Gbs a day. But if something goes wrong sods law says it will be in the 2 second window that is logrotate Anyhow that was a bit off topic On Fri, 4 Aug 2023 at 13:37, Ivo Herweijer via ruby-talk < ruby-talk@ml.ruby-lang.org> wrote:
You are welcome.
Ah, financial transactions. In that case it seems to me that you have two separate requirements: 1. Logging of requests, responses, errors. So the usual stuff to monitor the application 2. An audit trail of each financial event. In my opinion this does not belong in a logfile but in a database. So in a single database transaction: create the bet, lock the customer account, debit the customer account and create an audit entry. If the transaction succeeds happy days, if it fails try to create a failure audit entry and report back to the customer. If all fails (a Ruby exception) then hopefully the logfile will at least record the error.
On 04-08-2023 13:59, Peter Hickman via ruby-talk wrote:
1) There is the possibility that the missing information could be crucial. Clients are settling bets based on these processes. If things go tits up on a major event (think Football World Cup and the like) a lot of money could be at stake and if it is not our problem but we cannot prove it then we could take a financial and reputational hit. Besides not knowing what happened when it went wrong makes fixing it hard
2) We used to use the rotation feature that was built into the Logger package but we found in the past that when summer time happened the logger died because the new file already existed (not sure what was happening but moving the logfile with that days timestamp elsewhere fixed it). It was in our support calendar to check for this specifically until we had migrated everything to use the standard logrotate. This was years ago and this may be fixed now but testing it is not convenient when summer time changes happen only twice a year :)
3) syslog does look like the next thing to look at. I had a feeling that the most reliable alternative would be this. I will have to dig into it further
I have considered logging to a queue and have a reader create the actual log file but syslog will probably be the simpler solution
Thanks for you input
______________________________________________ ruby-talk mailing list -- ruby-talk@ml.ruby-lang.org To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org ruby-talk info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-talk.ml.ruby-lang.org...
______________________________________________ ruby-talk mailing list -- ruby-talk@ml.ruby-lang.org To unsubscribe send an email to ruby-talk-leave@ml.ruby-lang.org ruby-talk info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-talk.ml.ruby-lang.org...