They seem to be operating very well with the 2000 services (the number doesn't seem to have changed much in the last few years which is interesting, despite them adding new features, etc).
The domain is obviously very complex as its not just a ledger, but risk, loans, overdrafts, savings, etc as well as premium offerings, interacting with different payments networks like FasterPayments and Mastercard. Then there are the budgeting features, payments between friends, support system (Which is probably quite complex in its self), card issuing, internal dashboards and metric services, etc, etc, etc. I can easily see how this gets to 2000 services and I didn't even begin to think about the business accounts, US accounts, etc.
Those moving parts are defined by the complexity of the business. Banking software with 20000 classes deployed in J2EE application server on a mainframe would not be much different.
That's not really true, since microservices involve what boils down to RPC over a network. There are so many more failure modes involved when you have 2000 asynchronous processes talking to one.
That is true, but it also allows for much more orderly start-up and shut-down as well as automatic recovery. A service is a pretty well defined entity that can be exhaustively tested far easier than the corresponding monolith with 2000 classes and tons of non-local effects. To use processes for that purpose has definitive advantages. See "Erlang/OTP" for an example of how this can give you incredibly solid distributed architectures.
A friend of mine working for a rival neobank was telling me about a tiny piece of the whole thing that used 5 microservices to achieve it. This was a security related piece, and when I pressed him why something as simple as what he was describing needed 5 services, he went somewhat into detail, and it sort of made sense.
I can imagine 2000 microservices being rather low for a bank.
Not sure they're bragging about it - they're just stating it as context for their blog post.
And is 2000 moving parts too many? How many moving parts do you need to run a bank? I can imagine they're having to comply with ~2000 legislation clauses, for example. Isn't that just the complexity of their domain?
From my understanding the approach to microservices was more or less a day 1 thing due to some of the early engineering hires being very experienced with them; so the number of them was comparatively high pretty early on.
The domain is obviously very complex as its not just a ledger, but risk, loans, overdrafts, savings, etc as well as premium offerings, interacting with different payments networks like FasterPayments and Mastercard. Then there are the budgeting features, payments between friends, support system (Which is probably quite complex in its self), card issuing, internal dashboards and metric services, etc, etc, etc. I can easily see how this gets to 2000 services and I didn't even begin to think about the business accounts, US accounts, etc.