|
I'll do the actual math later but yes, I suspect somewhere between 25-50k/second would be required for a single system to handle wagering on the biggest events.
In the visa/mc example your talking sustained transaction amounts with a bit of burst at peak hours/days.
In racing we are talking very limited activity except a burst for 2 minutes each race. Any system must be able to handle well over the current known maximums.
And yes.. even when accepting transactions there would still need to be a cycle. It could potentially be sub-second but it could NOT be every wager. MC/Visa don't actually "cycle" except once per day. (Core Banking tech is likely farther behind in many ways than ourselves honestly..) They are better at hiding it and faking it on the frontend though!
---Edit
"System Load" isnt really the inhibiting factor in cycles or the reason you need to have them. Generally speaking system load is rarely ever a factor in anything today given distributed computing and on demand resources. It can get expensive, but its not a limiter technically. The actual limiter is how fast you can retrieve and store data, even in local memory there is a finite limit to how quickly you can lock data (pool total/matrix), retrieve it, modify it, store it and then unlock it again. In a distributed system you have to add in latency on each command and other variables. In reality the system I'm describing would have variable cycles to maintain a minimum but adapt to unknown circumstances.
__________________
Jason Martin
IT Director
AmWest Entertainment - AmWager
Last edited by Gorrex; 09-17-2018 at 07:29 AM.
|
