Quote:
Originally posted by charly
It would seem to me that if the transaction is recorded, the information would be stored as well.
If the system went down the transaction would not happen. So no info to store.
Or is this too simplistic?
|
Yes, it's way too simplistic. For starters, Visa/Mastercard and the acquiring banks mandate the security procedures that are used for transaction servers. They don't care about stats or anything else, since to them, it's all about transactions as well.
Next, why in the world would you store stats and transactions on the same server, even if there weren't a security vulnerability, since the load would be increased dramatically due to the stats using the database and the resources that run transactions?
Makes no sense whatsoever.
You set your transaction servers up, round robin, however you like, and those are the primary boxes and connections you sacrifice anything else to protect.
You then dump your stats from the transaction servers at fast, regular intervals into your stats system with a one way interface -- meaning no data from the stats system goes back into the transaction system to potentially cause harm.
Then you round robin your stats servers based on the load, which would come from the number of people checking stats on average at a time, and that's how you set up your stats servers.
IF there is a problem, then you yank the stats down or you stop feeding the new data into them until the problem is rectified.
Living by stats minute to minute is a waste of time in this business. Take rebills for instance, they are run daily at a scheduled time. Usually. However, if there's ever a problem with the transaction servers then rebills take a back seat since they are the closest thing to guaranteed revenue there is, and if you rebill them 8, 12, even 24 hours later than you originally intended, it doesn't change anything.
New sales are the lifeblood of this industry, followed by rebills, then you can stick stats in there as being important.
Hope that helps.