Revolut down as users report app not working
bbc.com
bbc.com
Got into a heated argument where the interviewer insisted it was perfectly acceptable to store money as a mutable row in a database.
I pushed back with the standard "You append transactions (including corrections) to a ledger" but he wasn't convinced.
I whipped out the standard two-ATMs -separated-by-a-distance overdraft example, and how you can create or destroy money that way.
He said it made no sense as an example because it was buggy and you would never release buggy code.
I asked if he'd done bug fixes before (yes) but obviously he was going to keep digging in further.
The irony of it was that he was part of the blockchain team.
who or what is mrkeen?
I have all the patience and time in the world to discuss my ideas.
I had the problems, the solutions, slide decks and a Miro board ready to go.
He wanted to shut down discussion at every turn with nonsense like "so you think no banks work at all?". Sure, I can grin and eat shit, or I can say "banks predate your CRUD operations by just a little bit".
If he had working knowledge on how to represent mutable money amounts in a distributed environment, he didn't let on. I was all ears.
So I pushed back on him, and I'll push back on you:
> even if you were technically correct why would a company hire someone...
Because I'm technically correct.
You're certainly not alone in your appraisal of the situation. The market over here works exactly this way. Correct, reliable systems come a distant second to agreeing with the team.
Technical discussions are incredibly likely to devolve into people discussions.
No people discussion has ever worked it's way back into being about fixing the broken software.
If anything, you dodged a bullet from a potential job where nothing gets done correctly.
Interviews are a gamble. If he interviewer has a specific framework in mind - no matter how correct or incorrect it is - good luck hitting the right spots.
i stand by what i said here down-votes be damned; judging by our brief interaction and your telling anecdote you come across as a smug disagreeable know-it-all and in their position i wouldn't have hired you -- there is after all the option to hire someone who both knows their stuff and doesn't come across the way you do
Oh Revolut's down are they? Let me tell you about an interview I did with them. Blah blah blah. Yeah, no thanks.
This is why I wrote:
Technical discussions are incredibly likely to devolve into people discussions.
No people discussion has ever worked it's way back into being about fixing the broken software.
I wouldn't dream of calling someone a smug disagreeable know-it-all.
I'm here for any discussion of the tradeoffs of balance v ledger, though.
You might be assuming that there is only one database, and that all consumers are reliably connected it. So who owns the database: Visa or MasterCard? Because ACID doesn't span across database instances (let alone database vendors or companies).
If you write down that "Bob withdrew $20", that cannot be wrong, (at best it can lack info that you later wish you had).
If you write down "Bob's balance is now $10", you already know the problems with that from your question.
You're right that I assumed there would only be one database or one ledger.
I'm assuming Revolut do as well, but this engineer wasn't aware. Or perhaps it was a different question they thought they were asking, or maybe a misunderstanding.
But the two ATMs problem would be solved by securing a lock on the database before proceeding with the transaction?
Who owns the database in your locked example?
How would a ledger work without having some kind of lock, how would you prevent a negative balance?
When someone checks their balance, would you to retrieve every transaction from the ledger and calculate the current balance?
If you have a protocol for interacting with your own database, you either need to rule out interacting with other systems (i.e. you have Revolut credits and you can only use them in the Revolut store,) or create a second protocol for inter-system transfers, in which case you have two protocols, and that second protocol won't play nicely with the first - e.g. partner bank informs you about a several new money transfers and a chargeback, meanwhile you're taking locks and directly setting balances. If the inter-system protocol is good enough, it will do everything the owned-locked-crud-database protocol would, and the crud is just going to get in the way.
You also have the problem of owning 'one thing'. If you lose 'one thing', you've wiped out all your records. Not to mention regular downtime from patching/releases etc. If for some reason you have the chance to use a database which presents itself as one-thing (but is distributed behind the scenes and has redundant replaceable parts) then whoever implemented that database is at the minimum using some kind of WAL (the 'ledger' of the database world), because those folks know they can't just have multiple masters CRUDding each other willy-nilly.
> How would a ledger work without having some kind of lock, how would you prevent a negative balance?
I wouldn't try to initially (but do see below). If the system can keep your balance from going below 0, then by CAP it's not available. If your supermarket loses connectivity or you're buying a cocktail while flying in a plane, your payment would just fail.
> When someone checks their balance, would you to retrieve every transaction from the ledger and calculate the current balance?
Pretty much everything in the concurrent space boils down to avoiding shared-mutable state. If you have it, your code is probably broken. Locking, ownership, defensive copies, immutability, etc. are all efforts to stay sane. If you go down the immutability path, more options open up. I use Kafka as the example. You append one new fact every time a money transfer happens. From a performance POV, Kafka scales horizontally, and appends only need negligible locking. I mention Kafka specifically because it also acts as the distribution. Different independent systems can follow it in near real-time, and they can choose to store and present the current balances, as a running calculation. And it works as long as you don't go back and edit history (corrections are appended instead.) As long as the kafka records are intact, you can always rebuild any other derived data from it.
If you did really need to forbid less than zero, you can model that in your events. Instead of emitting a MoneyMoved event, you could emit a MoveMoneyIfAvailable event. The reader of the system would see that event strictly in order (this is the key bit - you're basically using Kafka to gain linearisability in ACID-speak) and either emit a MoneyMoved event or a MoneyMoveRejected event in response. But again, this last trick doesn't mean you can order cocktails on a plane (if you tried to emit a MoveMoneyIfAvailable from up there, it wouldn't reach the server, and you also couldn't get the yes/no back anyway).
You can also let an overdraft occur. Now the user ows the bank some money and you can charge them interest for their debt.
Hey, not only he didn't believe in appending to a ledger but moreover he probably believed it was fine to store the amounts in floats (I know, I know, everybody who's using floats never make any mistake, knows everything about rounding rules, has read and could write by heart "What every computer programmer should know about floating-point numbers" etc. But I'm still not using floats for monetary amounts).
Row level locking and update indeed works, most of the time - bugs are a real issue.
som write ledger and update row in the same transaction.
then in bg have a batch ledger verification, probably on a read replica, and flag any discrepancy.
He's right, just make no mistakes!
Then they claimed my evidence was incorrect, without any opportunity to correct.
And finally in their complaint system they completely refused to look at any of the evidence and sent me a generic refusal letter that referred to me by the wrong name.
All this despite other banks successfully handling chargebacks for the thing in question. Sad.
Contactless is all fine and dandy but straight out refusal to handle cash is a big negative for the users, which is the only perspective anybody cares about. On top of obvious long term massive loss for society and personal freedom. Don't feed the actors that are harming you / us.
No cash means no freedom.
I'm also pretty sure it's illegal to pay cash for anything above 1000 €.
I'm curious how this legislation will end up, because the reason to push for cashless is that you should think of the children^Wterrorists. And much of this push comes from the EU itself (see chatcontrol).
The plans for harmonization are to have a limit of 10000 €.
> the EU itself
“The EU itself” isn’t a singular mind, it’s a forum with many participants and positions. In the end there needs to be a majority in the Parliament.
Sadly there is an increasing preponderance on the part of retailers to do one of two things:
1. Go card only (sadly happening in far too many places)
2. Make it incredibly difficult to pay by cash (e.g. 10 card tills, 1 cash till with long queues because it is also the cigarette/lottery ticket/package collection till)
This is why the apparently extortionate merchant fees. Precisely so that when you do swipe it always works no matter what. I genuinely cannot recall a single instance where I was unable to obtain payment auth in a grocery store using Visa or Amex.
Revolut is the biggest private company in all of Europe.
Perhaps it’s me but I still find it kinda wild that a single power outage in London can shut down Google DC and it can lead to Revolut shutting down for some time disrupting much of the economy which depended upon it
Perhaps this could’ve been prevented, which makes me wonder how much of code written at Revolut is ai generated and its ai policy?
As in not publicly traded? That's surprising, to be honest. How is that even measured?
But, yeah, certainly not by revenue, income, assets, number of employees, or any of the other metrics you might use for a private company.
No redundancy redundancy?
No redundancy redundancy?
No redundancy redundancy?
No redundancy redundancy?
Probably difficult if the cause is their cloud infrastructure being down.
https://www.theregister.com/paas-and-iaas/2026/10/20/google-...
Google cloud outage takes down HSBC, Revolut, Bank of Scotland, Lloyds, Equifax, more
Take with appropriate seasoning, given its anecdotal nature.
No need to wait for a bank and it doesn't matter the blockchain, as long as it supports USDC and you have a crypto wallet, the payment goes through.
Stripe knows this already and crypto payments will be here for a very very long time as they already are today.
If you were following Stripe for years, you would know that they are already using crypto for payments and it is here to stay.
So, approximately six 0s of uptime for my use case?
I didn't say bitcoin. I said blockchains that use USDC.
> So, approximately six 0s of uptime for my use case?
No-one cares if 1 person (out of 8 billion and trillions of bots) won't use it. It exists and Shopify and Stripe have crypto payments with USDC which is useful for both humans and agents.
the point was about physical flesh-to-flesh shopping experiences.
If they have a POS Terminal at their physical brick and mortar store powered by Shopify, they can do just that [0] and it accepts crypto payments.
The same for Stripe Terminal which allows contactless payments with stablecoins such as USDC [0] for physical stores. They can accept crypto from there and Stripe handles the transaction seamlessly.
[0] https://www.shopify.com/uk/pos
[1] https://www.privy.io/blog/contactless-payments-with-stableco...
Like can you pay with crypto at a Stripe POS when the infrastructure goes down? Or was this just completely irrelevant?
which makes sense, you'd either end up paying in pegged, virtual crypto dollars, or pay with a completely separate crypto currency which then means that the shoes you bought a month ago are suddenly worth a magnitude more or less. might as well pay in turkish lira.
[0]https://www.six-group.com/en/home.html [1]https://en.wikipedia.org/wiki/SumUp
Revolut, for example, has confirmed all its operations, that include, sign-ups, sign-ins, payments and transfers, top-ups, ATM withdrawals, stock trades, cryptocurrency, are all down.
For example, Phantom Wallet, MetaMask and Robinhood Wallet doesn't need a bank to make payments and send money anywhere.
2. This is Europe, we don't use USD directly or indirectly-via-backed-crypto for daily shopping.
3. Crypto comes in two layers: layer 1 which is too slow to replace interbank exchanges (which is much easier than everyone in Spain paying rent, which is much easier than everyone in Berlin buying lunch); and layer 2 which, as per memes about tech guys reinventing things which already exist, is reinventing the concept of a bank which is the thing here which fell over because the cloud it was on got unplugged.
Revolut’s “wallet” is managed by them and it is not the only wallet that exists.
2. We know and it does not matter since the EURC stablecoin exists today for that.
3. Most Layer 1 blockchains such as Solana, Stellar, XRP and Tempo are already fast (less than 10 seconds), worldwide with extremely very low fees for transactions.
2. Then USDC is irrelevant and you shouldn't have brought it up in this context.
3. Fees are irrelevant; worldwide is irrelevant; "10 seconds" is the wrong category of speed: throughput rather than duration.
Though 10 seconds isn't even fast in this context, payment cards are routinely used on e.g. the London Underground at the turnstiles, and anything over about 2 seconds would look like an error and that en-masse would cause noticeable queues getting into or out of the system and corresponding city-level commuting delays.
And normal card use in London public transport acts like a smart contract, as the fee isn't known on initial use, but when exiting the transport network later. Similar on hotels, from what I hear, though they handle it differently.
Both of these have a broader problem: anything on credit (which these function like as the final bill isn't known at point of sale) is fundamentally not part of the blockchain system, so even with all that, all credit cards need something bank-like (and if you use a smart contract to simulate this, you're taking on the risk of bugs in the contract).
From what I understand, TfL actually does all the hard work themselves and figures out the bill later, so if their DC went down the same time as Revolut's they'd not work even if this was a crypto solution that solved every other issue.
If I wanted to send money from my bank to another bank on Revolut, now I can't do that if GCP is down. Crypto wallets such as Phantom Wallet on the other hand can process that without needing GCP being up or down. That is the entire point of them.
2. There's a good reason why I said "stablecoins" and yes that includes USDC and EURC which are primarily used for payments; absolutely relevant for worldwide, instant low fee payments.
> Though 10 seconds isn't even fast in this context, payment cards are routinely used on e.g. the London Underground at the turnstiles, and anything over about 2 seconds would look like an error and that en-masse would cause noticeable queues getting into or out of the system and corresponding city-level commuting delays.
My point was towards the same ten seconds for buying physical goods. But since you want to switch the context and to talk about finality...
> From what I understand, TfL actually does all the hard work themselves and figures out the bill later, so if their DC went down the same time as Revolut's they'd not work even if this was a crypto solution that solved every other issue.
...technically TfL queues all these payments and they aren't finalized immediately. Even taking that time into account it takes from 12 hours to a day to finalize the payment for the travel after tapping a card on the reader.
But not a problem for blockchains like Solana which finalize even faster than that in 150ms rather than your slower example system of 12 hours.
So nope. There is a reason why an offline crypto wallet continues to work despite GCP and your bank going down at the same time and I can pay with a crypto card using Phantom Cash, but do go on.
$100B value down the drain.