I can't help but think this isn't the best idea, it raises so many questions. How does fail over work (it failed for me!), can you safely fail over, how does product think about the stack, is it funded well enough, how do you scale a system from zero to all traffic instantly, how do you effectively keep this environment warm, how do you determine which services are critical enough to be in it, how do you manage finding the bugs in two separate stacks, and so on and on and on.

It seems like it would be better to invest in a platform that is distributed across multiple failure domains. Some companies call this a cell architecture. For Monzo this might mean true multi cloud, but they already have bare metal services for bank integrations so they are already hybrid in some respects.

It's not the decision I would have made, and I'm not sure I agree with their reasoning, but I'll also admit that I have not run a bank, I don't know all their constraints, and there are some good tech folks at Monzo. That said, I am an SRE at Google so I'd like to think I'm not completely naïve here.

Edit: after reading in more detail I'm puzzled. The justification for Stand-In and not traditional scale-out is the difficulty of data consistency (agreed!), but then Stand-In is just eventually consistent anyway, and introduces sync problems in both directions. Admittedly I'm spoilt by Spanner, but I do wonder if Monzo is being bitten by past architecture choices here.

Fwiw to acquire a banking license and get the relevant approvals I believe you need to prove a redundancy plan that goes beyond just scaling.

I used to work in fintech where we’d face the same requirements and know a bunch of folks from Monzo. You can fight the status quo only for so long until it becomes much easier to just do what you’re being asked and produce a totally separate service that solidly answers any audit you may face.

For truly critical systems and independently developed redundant or backup system that can perform at least the most important functions is clearly superior. Regardless of how much effort goes into making one implementation reliable, there's always the possibility of an issue that takes it out, or forces it to be taken offline.

I don't know how common this is in retail banking but I'm happy to see Monzo do it.

monzo r the same guys who went in on micro services. at a time they were bragging 3 micro services per engineer. so yeah a lot of things don't make sense.

I'm a bit curious about Spanner. At $EMPLOYER we were going to do multi cloud with multi-region CockroachDB clusters but gave up on it because write latencies and costs were too high. Do you not get the same thing with Spanner, where technically you can have multi region but it's very unattractive to actually do?

No, it's a great idea. Any systems engineer knows redundancy is good, even better if it's across providers. I see no issues with this from a system architecture point of view. As to how the implementation is done that's up to them to do right.

I think the biggest problem is the data consistency. Since they are planning for eventual consistency, should make it easier, but they most probably had to re-write code to support atomic operations and proper transaction isolations.

But the scaling problem is still there, when they switched over I assume they would start both horizontal and vertical scale of k8 pods and maybe even bump up DB instances as well which could result in a small congestion at the start of the switch over

I suspect Monzo was bitten by complexity. The network should not be assumed to be reliable and if you make a thousand things (microservices) with network between them regardless of what you think may happen, it’s entirely impossible to test it with any level of certainty. And that’s worse if you have a complete failover scenario.

Add the instability of the average cloud control plane during an outage and things get rather nasty rather quickly in reality. We’ve been through that with AWS’ numerous outages.

My company is victim of this mindset. We sacrificed tested and assured reliability on physical hardware in multiple redundant data centres for cloud and microservices. Mostly driven by Monzo’s claims, semi religious thinking and me too.

Reliability is measurably down, cost is higher, latency is higher and we cannot fail over to another provider because someone went to an AWS conference and started using all the toys. Even if we did get rid of those dependencies, during an outage the kubernetes control plane is so tied into the vendor that we’d be fucked anyway. Last time the ingress controller couldn’t change ALBs for example.

Only winner here is Bezos and the decision makers CVs. The losers are the customers. We live in the stupidest of times.

So I've been spending a lot of time in the financial services/payment space and might be able to answer some of your questions.

The EU activated the Digital Online Resiliency Act (DORA) last year (passed in 2023) which, amongst other things, mandates that financial services providers who run their core business functions in the cloud (i.e. Monzo) must be able to demonstrate that they are not entirely reliant on a single cloud provider. Otherwise, big, big fines.

Like GDPR, there are auditors that are responsible for signing off on EU DORA compliance. Also like GDPR, there are ways to check those boxes without _really_ checking them. This is probably why Stand-In only has 18 services in its GCP failover "region" instead of the 1K+ production services in AWS; it's just enough to keep critical services (payments/card networks, balances, ledger, etc.) operational and, more importantly, keep DORA auditors at bay.

This article IMO is more for other FSIs who _want_ to run _entirely_ in the cloud (there are very, very few that do). Financial services is a very risk-averse industry. Most providers have biz-critical systems running on mainframes still. (Mainframes are practically indestructible and are much more technically-interesting than people give them credit for, but that's another post.) Being able to tell AWS "yeahhhhh we can run this business on GCP and/or Azure in literally 10 minutes" is a money line for procurement to use during price negotiations. Or at least it was until RAM prices mooned hard enough to make their existing datacenter inventory suddenly very attractive.

Cloud-aside, pretty much every bank in the US has some architecture like this for their critical banking systems, except they are usually an old-school hot-cold (sometimes hot-hot) datacenter failover strategy. Historically failover has been done manually with a runbook (with some automation) and tested during DR/BCP days (sometimes more frequently). They, of course, have zonal/regional replication in place.