(no title)
NJRBailey | 2 years ago
It's astonishing that of all the software engineers involved in programming and reviewing this system, not one of them thought to lock the DB records to prevent this (or worse, someone ordered them not to for some reason). It's so simple to do and should be top consideration when dealing with financial transactions.
Someone1234|2 years ago
All systems have trade-offs like these. It reminds me of the phase: "Anyone can build a bridge, but it takes an engineer to build a bridge that barely stands." That applies here. Any student can build a system with locking database records, but then when thousands of people's cards don't work for minute-long lockout periods, you aren't the one doing the CS calls or getting yelled at.
daveoc64|2 years ago
Each store would have a local copy of the card balances - but only for cards that had been used in that store in the past 12 months.
The first day you scanned your card in a store, you could only collect points (not redeem them).
By the next morning, your card would be included in the local database and you could redeem points - with the vulnerability that each store had its own database, and therefore you could redeem the points in multiple stores.
I thought this had been improved in recent years, but maybe not.
Suppafly|2 years ago
sp332|2 years ago
rwmj|2 years ago
arethuza|2 years ago